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.

You are comparing different memory management strategies, not languages features. All of those languages (C, Zig, C++ and Rust) give you enough choices when it comes to memory management.

You can decide to not use frequent heap allocations in Rust or C++ just as you can in Zig (it means not using large areas of the C++ or Rust standard libraries, while Zig definitely has the better approach when it comes to allocations in the standard library, but these are stdlib features, not language features).

That "just" seems to mean "you'll need to take 10x the time to write the equivalent Rust/C++ program". What a language makes easy to accompish matters.

Yes, it's true that you can do arenas in Rust, but they are harder to use in Rust, due to borrow-checking. For example you can't store arena in a struct without lifetime.

So in a language which actively makes your life miserable in the name of safety, you will likely just use Vec<T> because it's easy. Hence, back to the previous point - Vec<T> is slow -> your code is slow and it's not even obvious why because everybody does that so it looks like you're doing it right.