I think most of this is attributable to the ergonomics of compile-time expressiveness. C++ can effortlessly do things that require mountains of ugly boilerplate and macros in C or Rust. In principle they can express the same things but no one wants to write or deal with that ugly boilerplate so the equivalency is never realized in real code bases.
Zig is interesting because it slots in as a C-like language with a competent and expressive compile-time story. I don’t use Zig but I recognize its game.
Compounding on this, Rust is also unstable underneath, since there is no public, stable contract for carrying high-level semantics from HIR into MIR. Because these high-level invariants are lost during compilation, the compiler cannot easily use them to prove and eliminate low-level safety checks. But even if the frontend was perfect, Rust relies on LLVM's language-neutral SCEV, which operates purely on low-level math and cannot reason about high-level language semantics.
Ultimately, a lot of things would need to change for Rust to pay no performance for safety features.
let mut tab: [usize;100] = [0;100];
...
for i in 0..101 {
tab[i] = i;
}
This must panic at i=100. Panic becomes inevitable at entry to the loop.
Is the compiler entitled to generate a check that will panic at loop entry?
The slides suggest that Rust does not hoist such checks, and, so, with nested
loops, it has trouble getting checks out of the loop, which prevents vectorization.