That was the point I was trying to make, Zig isn't inherently faster than the other three. It just uses different default compilation options than clang, so any gains can be achieved in clang-compiled C or C++ too by tweaking compile options (and maybe using a handful non-standard language extensions offered by clang). Other then that it's just LLVMs "zero cost abstraction via optimization passes" and this works equally well across all 4 languages.

Or: the "optimization wall" in those languages is the same, only the effort to reach that wall might be slightly different (and this is actually where Zig and its stdlib might be better, it's more straightforward to reach the optimization wall because the Zig design philosophy prefers explicitness over magic)

I don't need any data to say that Zig is typically faster than Rust because I know that Vec<T> will do a shitload of useless work when it leaves the scope, even if the T does not implement Drop. You can do vec.set_len() but that's unsafe, so... Typical Rust is slower than typical Zig.

Zig does not do any work because it does not have smart pointers and it does not try to be safe. It tries to be explicit and predictable, the rest is my job.

BTW: This is very real, I've been profiling this and I couldn't believe my eyes. And even if they fixed it already there would be many similar footguns. You can't write performant software if you can't tell what work will be done.

The point was typical, typical Rust code is using Vec<>, typical Zig code is using arenas. Typical Rust code is using smart pointers, typical Zig/C code prefers plain, copyable structs.

It is 100% possible to use such style in Rust/C++ (and then the performance will be same or maybe even in favor of rust, it might be the case) but people usually do not do that.