whytevuhuni
As a Rust programmer I'm fine with cars driven by dogs, I just want that to be clearly acknowledged as unsafe, and if that car is be driven in public roads, I would also like a safety comment stating all the precautions taken to make that safe for others, preferably reviewed by the police as well.
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?
No shallow dismissals please, tell me why you think I'm wrong.
> Rust is not a major advance over C/C++
Rust adds the borrow checker (and especially with non-linear lifetimes it's an implementation like the world has never seen before, not even in Cyclone). That alone raises it leaps above both C and C++.
But even without it, it still has a Hindley Milner type system (which most people considered superior to multiple inheritance), it has Sync/Send traits, the concept of UnwindSafe, proper destructive moves and affineish types, proper sum types and matching, sane iterators, lack of UB on uninit/overflow/etc, a sane module system, hygienic macros, and that's just the things I was able to pull of the top of my head right now.
Not to mention, the design of its stdlib is absolutely lovely compared to what C++'s stdlib has become, and it focuses on correctness much more than most other popular languages.
Granted I doubt how true that is, I always understood the benefits of languages like Haskell and Ada/SPARK, it's just that pragmatically speaking I want beginners in my team to be able to code too.
We speak of the horrors of C/C++ precisely because we've seen both sides (3 sides more specifically), and can compare.
The sentiment of "if it compiles it probably works" for languages like Rust and Haskell is there for a good reason.
In my particular case I'm using Zed with type hints enabled, so the editor displays that expression as `let i: usize = 1;` automatically (which is really useful in a language with type inference, especially with expression as weird/complex as Rust iterator method chains). You're right that I wouldn't know if I were to open the file in a simple text editor.
There's a lot of safe but slow languages, Rust is trying incredibly hard to be a safe language that is still seen to be in that general C/C++ ballpark of performance.
Maybe? I'm not sure.
> The proof that there are no (for rust's definition of "no") memory bugs becomes worthless
I still don't think so, the proof that there are no memory bugs is definitely not worthless, since while the whole proof itself is binary (it is either fully correct or not), its effects act more like coverage, and the more of it that happens to be partially correct, the better.
I think cve-rs is the perfect example of this. Its very existence proves that the borrow checker is already unsound, and with that, the very foundations of Rust's safety guarantees are currently flawed.
TypeScript is another good example, its type system has been repeatedly proven to be unsound, so it's also flawed.
But so what if it's flawed? Many smaller properties of these proofs still happen to hold, and they might prevent 90%+ of CVEs even as flawed as they are.
It’ll most likely still do 99% of the things people need it to do, there’ll be a an issue created for that broken 1%, and eventually it’ll be iterated upon and fixed.
Unless you’re working on a security boundary of course, there you should treat it like maths.
Maybe in the future the unsafe code will go down to 1%, bringing that to two orders of magnitude.
Of course, only time will tell if that is true or not, but from experience I’d be willing to bet it is.
That's the power of Rust, not a limitation of it. Rust thrives on its ability to provide safe interfaces over unsafe code.
You'll see this practice in other languages too; if you're coding safe Java, you're using a lot of unsafe code from the JVM and via JNI.
If you're using Python, the stdlib and all the performance-sensitive libraries (numpy, pandas, etc) are written in unsafe code, but even when you import those we still say your Python code is safe, and that Python overall is a memory safe language.
On the contrary, that has been one of Rust's biggest strengths. My impression when reading through stdlib was that they got so many things right, and for that to happen, things need to be thought out properly.
Case in point, it'd be such a shame if they stabilized the allocator API, only for us to forever regret never getting the storage API [1] instead, or vice-versa, depending on which one turns out to be more pragmatic.
> they also have a kind of perfectionist culture as a reaction to all the half baked features shipping in C++.
And that's a good thing! Some people really dislike the constant influx of new features due to the overwhelming complexity it leads to. So if we do have new features, they better be worth it.
Granted the premise is rather brittle, since all Cpp2Rust does is to convert UB to runtime crashes, which can be undecidable, and cannot be used to prove anything about the original C++ code.
I'm not using panics, and yet I'm getting the machinery. That is where my frustration is coming from.
The problem comes from a combination of three things:
1. Rust's standard library (including core) likes to panic a lot, e.g. for code that is genuinely unreachable (and this is fine)
2. Rust/LLVM cannot always optimize unreachable code away (and this is also fine)
3. The presence of at least one panic causes Rust to also include the error string format machinery, which is HUGE (and this is completely unavoidable)
Because of #2, there is no way to prevent this for larger code. I can define my own panic handler, but I can't prevent panic!() calls from inside core from constructing the format message using core::fmt before they call my panic handler.
And so any non-trivial code sometimes just randomly becomes 3x larger, and I can no longer fit it on my MCU, despite never actually printing or caring about any panic messages.
First of all, I was amazed by how much I could do with Rust (safe Rust, even), and how well it was interfacing with my handwritten RISC-V assembly. I will definitely use Rust again for the next such project.
But, every time my functions would get over a certain size, suddenly some optimizations stopped working, and Rust was trying to put the whole panic/fmt machinery into the thing, going above my linker's flash size limit. It was insanely frustrating, since there was no rhyme or reason to it. Simply adding another branch to a match made it do that. Or another if statement that was exactly the same as the 4 before it.
The 137 binary thing does not scale.
That's because closely following PL theory isn't always the right goal for a language. Ergonomics and pragmatism are far more important.
Sadly, Gentoo is not great for managing per-project dependencies in the same way as is done by npm, pipenv, etc. Nix however works great (if you can stomach its stdlib).
How does Rust differ from C++ in this regard?
As far as I know, both use RAII, and offer something RC-like in their stdlib that is optional to use.