2 ms·

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 t

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.

fooker 10mo ago
> 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.
- ahartmetz 10mo ago
  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.
  - fooker 10mo ago
    You’re right. That’s not what my point was about though.
- tialaramex 10mo ago
  > 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++.
  - fooker 10mo ago
    > 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.
    - tialaramex 10mo ago
      Rice's Theorem says we can advance arbitrarily close but can't reach the goal of compiling exactly the set of correct programs (all correct, none incorrect). Some years ago Rust landed "Non-lexical lifetimes" borrow checking which is an example of such an advance, you don't need to overturn mathematics to make such advances, only to reach the goal. Work to further improve lifetime checking is ongoing though I doubt anything as big as NLL is on the foreseeable horizon. The problem isn't directly with C++ choosing "All correct programs compile" but instead with the resulting incentive structure. Programmers want their program to compile. In Rust the incentive is to improve the compiler, allowing more programs (all of them correct) to compile as with the NLL changes. But in C++ the incentive is to loosen the requirements, allowing more programs (some of them incorrect) to compile, as with Concepts Lite in 2020.
    - 10mo ago
- hulitu 10mo ago
  > than it is to design a language that does not require you to jump through hoops to get something correct to compile. They are doing the same to C. With gcc 15 all warnings are treated as errors.
  - irishcoffee 10mo ago
    -Wall/-Werror/-Wextra have existed for a long, long time. -Wno-error will still work in gcc15, which quickly defeats the point of werror being a default. If your're writing c/c++ in 2026 and not using wall/werror/wextra, you're actively choosing to compile unreliable code and you should have been jumping through those "hoops" the whole time. "But, all my dependencies!" Fork them and fix the warnings. Flow the changes back upstream. Use your fork if they're not accepted. Don't buy libraries that compile with warnings, or demand your vendor fix them. I've been writing c/c++ for a long, long time. The bugs that actually bite you are almost always logical and have little to do with things like a borrow-checker, ask cloudflare.
    - fooker 10mo ago
      > The bugs that actually bite you are almost always logical Exactly right! I would bet that the more time you spend fighting the programming language and compiler, the less you are thinking about complex logic.
timschmidt 10mo ago
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.

fooker 10mo ago

> 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.

ahartmetz 10mo ago
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.
- fooker 10mo ago
  You’re right. That’s not what my point was about though.
tialaramex 10mo ago
> 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++.
- fooker 10mo ago
  > 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.
  - tialaramex 10mo ago
    Rice's Theorem says we can advance arbitrarily close but can't reach the goal of compiling exactly the set of correct programs (all correct, none incorrect). Some years ago Rust landed "Non-lexical lifetimes" borrow checking which is an example of such an advance, you don't need to overturn mathematics to make such advances, only to reach the goal. Work to further improve lifetime checking is ongoing though I doubt anything as big as NLL is on the foreseeable horizon. The problem isn't directly with C++ choosing "All correct programs compile" but instead with the resulting incentive structure. Programmers want their program to compile. In Rust the incentive is to improve the compiler, allowing more programs (all of them correct) to compile as with the NLL changes. But in C++ the incentive is to loosen the requirements, allowing more programs (some of them incorrect) to compile, as with Concepts Lite in 2020.
  - 10mo ago
hulitu 10mo ago
> than it is to design a language that does not require you to jump through hoops to get something correct to compile. They are doing the same to C. With gcc 15 all warnings are treated as errors.
- irishcoffee 10mo ago
  -Wall/-Werror/-Wextra have existed for a long, long time. -Wno-error will still work in gcc15, which quickly defeats the point of werror being a default. If your're writing c/c++ in 2026 and not using wall/werror/wextra, you're actively choosing to compile unreliable code and you should have been jumping through those "hoops" the whole time. "But, all my dependencies!" Fork them and fix the warnings. Flow the changes back upstream. Use your fork if they're not accepted. Don't buy libraries that compile with warnings, or demand your vendor fix them. I've been writing c/c++ for a long, long time. The bugs that actually bite you are almost always logical and have little to do with things like a borrow-checker, ask cloudflare.
  - fooker 10mo ago
    > The bugs that actually bite you are almost always logical Exactly right! I would bet that the more time you spend fighting the programming language and compiler, the less you are thinking about complex logic.

timschmidt 10mo ago

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.