I understand that anytime someone brings benchmarks out, the next response points out that benchmarks are not real world use cases. Nonetheless, they are data points, and your claims are against the commonly accepted view of C being roughly as fast as C++ and Rust. If you have absolutely no data to back it up, you shouldn't expect anyone to believe you.
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.
I'm a Zig fan and all, but you should probably check if your C/C++/Rust code uses the equivalent of "-march=native", that might already be responsible for most of the performance difference between those and Zig - they all use the same LLVM optimization passes after all, so excluding obvious implementation differences (like doing excessive heap allocations) there isn't any reason why one would be faster than the other.
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.
Zig is in the same ballpark as the ones mentioned above, so flohofwoe is right. But nevertheless I do think that cztomsik's point also still stands: how hard it is to make something fast will end up impacting the performance characteristics of the average program and library out there, and Zig does make it easier to write performant code than some other languages.
> Zig can and does win plenty of those benchmarks, but ultimately it boils down to who is it that gets nerdsniped into working on a specific challenge.
That was a faulty benchmark with a simple unnatural footgun that the Rust people overlooked. I don't think it supports your claim that benchmarks typically boil down to who is it that gets nerdsniped into them. Sure, it can happen, it happened at least once, but in general?
https://programming-language-benchmarks.vercel.app/c-vs-rust
I understand that anytime someone brings benchmarks out, the next response points out that benchmarks are not real world use cases. Nonetheless, they are data points, and your claims are against the commonly accepted view of C being roughly as fast as C++ and Rust. If you have absolutely no data to back it up, you shouldn't expect anyone to believe you.