That is a good point, but I think "idiomatic" here deserves some elaboration. Often people use it in very vague way: this is what (outspoken) programmers agree

That is a good point, but I think "idiomatic" here deserves some elaboration. Often people use it in very vague way: this is what (outspoken) programmers agree is the best way to do this thing. In this case, I think a more limited and specific definition is sufficient: don't use escape hatches. Don't use "unsafe" or compiler-specific extensions or inline assembly or libraries that were actually written in assembly. What can you do in the language as it comes out of the box, as every tutorial would lead you to do? I think Zig could indeed be "faster than C" in this sense, as others have pointed out Fortran can be, but Rust might not be able to. There's also an important lesson here about optimization BTW. Everyone thinks of optimizing algorithms in terms of big-O stuff, and that's great, but sometimes data size or layout or frequency of pointer-chasing or mispredicted branches can actually be the real difference makers. Cache-friendly vs. cache-hostile code can be particularly hard to spot, because it often doesn't show up even in most kinds of profiling. It presents only as a sort of general performance degradation across the board unless you're specifically looking for it. I've implemented significant performance gains just by rearranging code and scheduling to make better use of a processor's L1 I-cache. The gains to be had from doing the same for data in L2 and L3 caches are even greater. I appreciate that Zig is being designed with these issues in mind, because it seems like a lot of other newer languages are being designed with the specific goal of defeating modern computers' performance-enhancement techniques.