Comment by tialaramex
3 hours ago
Some of this is just knowing from experience, by the time C++ programmers knew they wanted the destructive move assignment semantic at the turn of the century they already had large codebases which relied on C++ copy assignment, so, too bad. It took a significant extra effort to land C++ 11 move semantics, which are still less useful but also have worse ergonomics. Whereas Rust knew it wanted the destructive move so, that's just how everything works in Rust.
But there are a bunch of unforced errors in C++ design beyond that. Default implicit conversion is a choice and a mistake. Multiple inheritance is a mistake, Stroustrup even says he did it because it was easy, which is exactly the same cause as Hoare's NULL. Choosing "All correct programs compile" (the other option was "No incorrect programs compile", you can't have both, see Henry Rice's PhD thesis) was a mistake. My favourite bad default in C++ is atomic memory ordering. The nasty trick here was that picking a default was the mistake, it's not that they picked the wrong one but that they picked a default at all. C++ programmers end up writing code which doesn't specify the ordering even though the ordering was their only important decision.
Agreed. C++ has advanced incredibly over the years, with the developers putting in immense, important, and useful effort. But Rust has had the benefit of a fresh start with lessons learned. People who have yet to understand the choices made in it's design see the differing semantics as unnecessary hurdles, whereas people who've taken the time to learn why those choices were made and what adhering to them enables find themselves enamored of their newfound abilities. It's why there's such an intense communication rift between folks on either side of the experience.
> Choosing "All correct programs compile" (the other option was "No incorrect programs compile", you can't have both …
This is really the important distinction between C++ and Rust.
In my opinion, it seems easier to complement the former to catch issues afterwards (like this article) than it is to design a language that does not require you to jump through hoops to get something correct to compile.
I hope programming language design progresses to a state that makes my point invalid, but the “bro rust is easier than C++” gaslighting culture does not help.
I'm quite experienced at C++ and not that experienced in Rust... but I believe that writing correct Rust is easier than writing correct C++. People get C++ to compile alright, but it often has problems at runtime. You need to know what you are doing in both, but C++ allows you to compile with certain classes of bugs anyway. Even experts still occasionally introduce bugs in C++ that Rust wouldn't allow.
You’re right.
That’s not what my point was about though.
> In my opinion, it seems easier to complement the former to catch issues afterwards (like this article)
Fil-C of course can't magically fix your incorrect program. It never had any defined meaning, but the compiled executable does something and Fil-C will ensure that if the thing it does involves say, a use-after-free at runtime now it exits reporting the error, but it can't fix the fact it's nonsense, that's not their purview.
There's no point in hoping that somehow Programming Languages will overturn Mathematics. I mean, I can't blame you for trying, Bjarne Stroustrup is a professor and still seems to think that should be attempted, but it's futile. We're definitely talking "Why can't I extinguish the sun with water?" level thinking.
Obviously I can't speak to your own experience but for me certainly Rust is easier than C++.
> There's no point in hoping that somehow Programming Languages will overturn Mathematics.
Maybe you misunderstood my point?
Getting rust to a more complete state would be overturning mathematics here, as you note you can’t have both soundness and completeness.
What I say does not require overturning mathematics, ie allow unsound programs to compile but have different methods of catching them, both statically or dynamically.
1 reply →