I've had to refactor a heck of a lot more C++ than Rust. C++11, std::optional, concepts and ranges, std::format, etc. It's not even that I dislike these changes necessarily, but you're always rewriting C++ to keep up with the language.
In rust it's mainly been nightly stuff getting merged to stable, pre-1.0, and async. Much more stable overall.
> you're always rewriting C++ to keep up with the language
If that's what you want to do, which is a big if. I guess strictly speaking the same is true for Rust but in Rust, with it being new, it "feels" more like I should keep up (at least for me). In c++, I would mostly just not mess with old code that works...
I'm approaching this from an enterprise perspective of "how confident am I that this code is safe and correct?"
If you hand me a pile of c++03 code that happens to compile, my confidence in it meeting both of those criteria is fairly low. If you ask the standards committee or bjarnes, what they're going to tell you is to rewrite it in modern C++, which constantly evolves.
Contrast that with rust where it's probably fine if it compiles.
> standards committee or bjarnes, what they're going to tell you is to rewrite it
The same will be true for Rust in 50 years (assuming Rust doesn't die any time soon). If they didn't think it was worth modernizing, they'd just leave C++ alone (which I think they should, but that's another matter).
For old C++, you run valgrind and a linter on it and if nothing comes up it's also "probably fine". At least it's hard for me to think of a situation where the most productive/profitable-for-buisness thing a developer can be doing is modernizing their old C++.
Would you bet your life/money/application security on valgrind and a linter being sufficient to catch all of those issues, knowing that a single mistake invalidates every guarantee the standard gives you? That's the situation we're in with C++.
When you're building old code, the compiler can't check that it upholds the standard to the degree that it can for modern C++. That's why the advice is to update the code, because the tooling can't save you otherwise.
Rust by contrast guarantees that you either have a compiler/runtime bug or the issue is more narrowly localized than "potentially every single line of code". Sure, I'd like better, but it's an improvement.
Definitely not. But it's rare that so much is at stake. I would not bet my life on the borrow checker either, there's a lot of things that can go wrong in a program.
Money is of course a question of how much. Application security is just "the above". The "undefined behavior can explode your PC, travel back in time and become your father" problem is not to be underestimated. However, in cases where old code works well for years but really has some lurking bad UB, one can disable some optimizations and be conservative with compiler choice. A lot of people dislike the trend towards compilers being ever more punishing of UB and I can see their point, while it's of course hard to argue for (let alone find) a balance between performance and some robustness to ubiquitous and almost inevitable code issues.
Rust's giarantees are nice and I sure would prefer working on a modern Rust project than any C++ project, as well as a modern C++ project compared to C99-with-classes. Modernizing existing code is a different matter. I've seen very few attempts at modernizing a big and old C++ codebase, no attempts where it clearly paid off and one attempt where it went wrong...
The amount of new syntax and programming concepts being constantly crammed into C is much smaller. If I had to quantity it, I'd estimate that C++ is by now roughly 3.5 programming languages in one while C is maybe 1.5...
The more stuff you have the more problematic (adding foot guns and making it hard to learn a language) it is to add more stuff because it all interacts. And a lot of C++ features interact in bad ways...
In rust it's mainly been nightly stuff getting merged to stable, pre-1.0, and async. Much more stable overall.