[dead]
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?
Good thing Rust doesn't just fix that one class of problems, but also provides better tooling to fix other classes too. Classes of problems that could be fixed with the other features of Rust mentioned later like the Hind...
> Blah blah blah. Most of that is just added runtime complexity that I could add to C if I wanted, but why would I?
...the vast majority of these features don't even run at compile time. Some of them can't even be implemented in C. For starters, show me an example of a Hindley Milner type system implemented for C (how can someone improve a strictly compile time feature, static typing, with a runtime implementation is beyond me). Or proper destructive moves in C or C++.
> Ada is the language to emulate, [...]
Good thing Rust also takes from Ada.
> Again, the actual successor to C/C++ looks nothing like Rust.
And that would be...?