> Yes, except imagine the distance in correctness between Assembly and C, and triple it.
* laugh track deafening *
> The sentiment of "if it compiles it probably works" for languages like Rust and Haskell is there for a good reason.
It could compile and still have 10,000 logic errors.
Rust is not a major advance over C/C++, only an incremental and quite limited one, which will require decades of rewriting perfectly good code to gain its dubious benefits, in the process introducing numerous other errors.
But don't take my word for it, I'm just the guy who--as usual--is aware right now of facts the rest of you will slowly figure out over the next 20-30 years, after the hype has worn off and you're left with the sad mess that is Rust.
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.
> No shallow dismissals please, tell me why you think I'm wrong.
Tell me why you think you're right.
Hint: you're wrong.
> 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++.
No, not really. It's an incremental improvement at best.
In time you will learn about all of the faults and flaws in Rust, after you've suffered the pain of trying to rewrite the entire universe in it just to fix one single class of problem you are obsessed about--inevitably introducing many new bugs in the process, because that always comes with the territory.
I know exactly what the successor to C/C++ looks like, and it's not Rust.
> 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.
Blah blah blah. Most of that is just added runtime complexity that I could add to C if I wanted, but why would I? None of that crap is needed. Most of it is wankery, the sort of stuff that 20-somethings salivate over but which in the end is meaningless, just change for the sake of change.
> 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.
Ada is the language to emulate, not Rust or C++. Again, the actual successor to C/C++ looks nothing like Rust.
> It could compile and still have 10,000 logic errors.
It could. Switch that to C or C++ and the amount of logic bugs is likely going to triple.
> Rust is not a major advance over C/C++, only an incremental and quite limited one, [...]
"Nothing ever happens." I guess you could consider borrow checking, an actual module system, type classes, enum variants, compiler-integrated macros, async/await, etc. to be just small increments. (Theoretically, you can reimplement most of this in C++, like std::variant, but they don't integrate well into the language - having to declare a type just to use std::visit is certainly not as simple as using match).
> [...] which will require decades of rewriting perfectly good code to gain its dubious benefits, in the process introducing numerous other errors.
"Introducing numerous other errors"? Would be interesting to see an citation on that. From what I've seen, these "new errors" were already present in the original "perfectly good code", except the original also had instances of undefined behavior and logic errors from poor type modeling.
> But don't take my word for it [...]
Why would anyone other than your friends take your word? You could have substantiate your claims with actual evidence.
> [...] after the hype has worn off [...]
Which already did. Nowadays, I see more posts about Zig and Fil-C.
>[...] left with the sad mess that is Rust.
I went to read your comment history to see if you elaborated on this "sad mess" of Rust, but you didn't. How about you do it here?