> (in safe-mode only, of course)

Then it seems to me that Rust still has an advantage, in that it offers full protection of UAF with zero runtime overhead.

That's like saying that a helicopter clearly has the advantage over a car in that it can fly. True, that's an advantage, but you don't get to just pick the advantages -- they come in a package. That package is better overall only if the advantage comes at no additional cost and has no associated downsides. I, for one, think Rust's advantages comes with a hefty price tag, and can have negative effects even on correctness compared to Zig. However, it's hard to intuit which of the approaches is better for correctness; only time and empirical observation will tell.

This isnt quite true, the borrow checker forces us to use things like RefCell, or Vec with (generational) indices, which all have run-time overhead. (this isnt even counting those who use Rc)

If takes twice time to write?

Of course, I too believe statically verifying is important for mission critical software. But it comes with a cognitive overhead.

It takes some time to get up to speed with Rust, but I don't think it takes particularly longer to write a correct program in Rust than it does in other languages. I often find myself reaching for Rust rather than Python now, even for small things.

The same is true for C++, and early reaction was similar: hey, we don't need high-level languages anymore! But after a few decades with C++ we've found that the burden manifests not when writing the program but when maintaining a large codebase over many years in a team whose members change over time.

I've used C++ since the 90s and it's only ever been presented as a Serious Language for Real Applications. I feel that until recently, C++ stood alone and there were almost no serious threats to its position, except maybe Java. If you were planning on writing commercial programs (or even more so a collection of programs) that have good performance and huge featuresets, like an operating system or a browser, what else could you have possibly used?

I agree that in practice maintenance has been pretty bad for C++ programs, but I think I understand the kind of reasoning that led so many organizations to pick C++, even if I don't agree with it. It was not about ergonomics or productivity, but about control. The language grants an unprecedented level of power to a small group of elite programmers inside every organization, who author the standard library and headers that all the other programmers use. They're building the smart pointers, the memory allocators, the IO libraries, and the build systems. It's imperative (to them) that their good decisions don't get snowed under the mountain of application code that the more mediocre programmers are going to be producing by the truckload. So it's important to have powerful encapsulation, compile-time checks, and metaprogramming capabilities. Doesn't matter how safe by default or how slow it all is, because the elite add guarantees themselves through the abstractions they write, and don't have to compile a full application very much, if ever.

I have heard this statement ~~repeated~~ monomorphized so many times here without mentioning reasons that I don't believe it anymore.