whytevuhuni
Joined 3 years ago
Karma
397
Submissions
238
Member since
Sep 30
Recent submissions
Comment · 2 months ago
Why is that? What do those have that embassy does not (or vice-versa)?
Comment · 2 months ago
> cars are to be driven by qualified humans only
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.
Comment · 3 months ago
> Tell me why you think you're right.
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?
Comment · 3 months ago
> * laugh track deafening *
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.
Comment · 3 months ago
The Blub Paradox [1].
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.
Comment · 3 months ago
Many Rust proponents are experienced C programmers (me as an example).
We speak of the horrors of C/C++ precisely because we've seen both sides (3 sides more specifically), and can compare.
Comment · 3 months ago
Yes, except imagine the distance in correctness between Assembly and C, and triple it. Less so compared to C++ of course.
The sentiment of "if it compiles it probably works" for languages like Rust and Haskell is there for a good reason.
Comment · 3 months ago
How much of Valhalla is this? 50% of it? 90% of it?
Comment · 3 months ago
Probably dance.
Comment · 3 months ago
Yeah, this has come up a few times when I was coding Rust. From just reading your code I know for sure that i is a usize (indexing is very common), but don't know what j is (I usually expect Rust to throw some kind of "could not infer integer type" compiler error, and it doesn't do that here). I'm guessing maybe i32. Code at the end of the function changing the meaning of code at the beginning of a function has also surprised me a couple times.
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.
Comment · 3 months ago
In production you generally want your code to not be 1.5x-2x slower than C/C++, otherwise people will ditch your whole language with all its other benefits in pursuit of performance.
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.
Comment · 3 months ago
Rust helps prevent some race conditions, but an unqualified "prevents race conditions" sounds like it eliminates them, hence why GP says it does not.
Comment · 3 months ago
> So you haven't understood the distinction or you're letting your feelings for software get the best of you.
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.
Comment · 3 months ago
I’ve understood the distinction. I just don’t like you equating “actually not safe” with “worthless”.
Comment · 3 months ago
Of course, but even the presence of CVEs does not make software worthless, it just makes it worth less.