Google fixed more Chrome bugs in June than over the past two years, thanks to AI

The more verification you do, the more likely it is for a program to be correct. Lean towards Assembly, and you get less correctness, but lean towards Ada/SPARK, and you get more.

Rust is a notoriously difficult language specifically because it adds some limited verification features, going further along that correctness continuum than C. I didn't think that could even be disputed.

The "if it compiles it probably works" feeling most Rust programmers experience is proof that those verification features work, too.

> In time you will learn about all of the faults and flaws in Rust

I've programmed enough safe Rust and unsafe Rust that I'm now very familiar with most of its flaws, and yes, it has many. I'm also familiar with C and C++'s flaws, and they're so, so much worse.

> after you've suffered the pain of trying to rewrite the entire universe in it

My goal has never been to rewrite the universe in Rust. Battle-tested software is fine to stay as-is, unless it needs constant updates and new features, where most memory bugs appear.

With that said, a couple years ago, at work, our team finished migrating a couple of performance-sensitive services from C++ to Rust, and not only were they both successful, but they became 5x and 10x faster respectively, because it's so much easier to do direct memory reference stunts that would've been possible, but crazy via C++'s std::span and lambdas.

> I know exactly what the successor to C/C++ looks like, and it's not Rust.

What does it look like?

> Blah blah blah. Most of that is just added runtime complexity that I could add to C if I wanted

Everything I listed is compile-time complexity. I'm not sure how you can add any of it at runtime without extra runtime costs. Or are you talking about modifying the C language?

We might argue over whether that complexity is worth it, for sure, but once again: "if it compiles it probably works" is a very common sentiment with Rust.

But also, what you're saying sounds very much like the Blub Paradox [1]:

"As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub."

[1] https://wiki.c2.com/?BlubParadox

> Most of it is wankery, the sort of stuff that 20-somethings salivate over

I'm not sure how that is relevant to what I said? I have 30 years of experience with C, and have read the C specification cover to cover, plus more recently some 15 years of C++ experience in parallel at work. I still use all 3 languages today.

> Again, the actual successor to C/C++ looks nothing like Rust.

What does it look like?

Or you can bury your head in the sand while the rest of the industry is moving on, I guess.

The industry as a whole throws away orders of magnitude more engineering-years _daily_ in meetings discussing if scrum standups are effective.