That only makes sense if all your code is in Rust, but I suspect this is not true for foreign libraries, even bulletproof ones. It was my understanding that to convince Rust of their safety, you need blocks of "unsafe" code...or not? For example, if I want to embed Chez Scheme into a Rust program, even safely, I apparently can't do that without "unsafe" code. And that's by no means exclusively a "low-level/hardware related thing".

(Yes people, and Apple should try, but...)

Taking Rust as an example (use Swift or even Java if that works better for your use-case), we know how to write Rust code that is guaranteed to be free from common classes of bugs that these zero-click attacks exploit.

Yes, we aren't going to get rid of all bugs, yes, zero-click attacks might still be possible once in a while, but we can make it much, much harder and more expensive, and therefore greatly reduce the set of people who have access to such attacks, and reduce their frequency.

No we don't.

You are trying to shift the sands, by saying "But.. this one thing we can do...", except even that isn't true.

If we did, it wouldn't keep happening, year after year, decade after decade.

But even with peer reviews, with people supposedly knowing how, well.. it just keeps happening.

Do you think every occurrence is random chance? Or is it, maybe, just maybe, that humans can't write bug free code?

Safe Rust code could trigger a compiler bug that leads to use-after-free, or trigger a bug unsafe Rust code (i.e., code explicitly marked "unsafe") that leads to use-after-free; the latter are rare, and the former are even rarer. In practice I've been writing Rust code full time for six years and encountered the latter exactly once, and the former never. In either case the bug would not be in the safe code I wrote.

I'm certainly not claiming that humans can write bug-free code. The claim is that with the right languages you can, in practice, eliminate certain important classes of bugs.

So there will be no human error? And rust will have zero compile time bugs, ever?

I'm not against improvement, but the absurd assumption that anything is safe. Because nothing is.

> Someone in the thread said he has 30 years experience in programming, and the only new lang which is really close to C in speed is Rust.

He has a point. Both C and release-mode Rust have minimal runtimes. C gets there with undefined behavior. Rust gets there with a very, very robust language definition that allows the compiler to reject a lot of unsafe practices and make a lot of desirable outcomes safe and relatively convenient.

However, Rust also allows certain behavior that a lot of us consider undesirable; they just define the language so that it's allowed. Take integer overflow, for instance https://github.com/rust-lang/rfcs/blob/26197104b7bb9a5a35db2... . In debug mode, Rust panics on integer overflow. Good. In release mode, it wraps as two's complement. Bad. I mean, it's in the language definition, so fine, but as far as I'm concerned that's about as bad as the C https://stackoverflow.com/a/12335930 and C++ https://stackoverflow.com/a/29235539 language definitions referring to signed integer overflow as undefined behavior.

I assume the Rust developers figure you'll do enough debugging to root out integer overflow happens, and maybe that's true for the average system, but not all! I once had to write a C++ program to compute Hilbert data for polynomial ideals. The data remained relatively small for every ideal that could reasonably be tested in debug mode, since debug mode is much slower, after all. But once I got into release mode and work with larger ideals, I started to encounter strange errors. It took a while to dig into the code, add certain manual inspections and checks; finally I realized that the C++ compiler was wrapping the overflow on 64 bit integers! which is when I realized why several computer algebra systems have gmp https://gmplib.org/ as a dependency.

OK, that's the problem domain; sucks to be me, right? But I wasted a lot of time realizing what the problem was simply because the language designers decided that speed mattered more than correctness. As far as I'm concerned, Rust is repeating the mistake made by C++; they're just dressing it up in a pretty gown and calling it a princess.

This is only one example. So, sure, Rust is about as fast as C, and a lot safer, but a lot of people will pay for that execution boost with errors, and will not realize the cause until they've lost a lot of time digging into it... all to boast, what? a 1% improvement in execution time?

IMHO the better design choice is to make it extremely hard to override those overflow checks. There's a reason Ada has historically been a dominant language in aerospace and transportation controls; they have lots of safety checks, and it's nigh impossible to remove them from production code. (I've tried.) Nim seems more like Ada than Rust in this respect: to eliminate the overflow check, you have to explicitly select the very-well-named --danger option. If only for that reason, Nim will seem slower than Rust to a lot of people who never move outside the safe zone of benchmarks that are designed to test speed rather than safety.

To be fair, once you remove all these ~1% slowdown checks, you get a much higher performance boost. And Rust really is a huge improvement on C/C++ IMHO, with very serious static analysis and a careful language design that isn't encumbered by an attempt to be backwards compatible with C. So if you're willing to make that tradeoff, it's probably a perfectly reasonable choice. Just be aware of the choice you're making.

The key takeaway is the following: Rust programs will contain bugs, but none of those bugs will lead to the kind of crazy vulnerabilities that allow those “zero-click attacks”. Is that perfect? No, but it's an enormous improvement over the status quo.