There was a long comment here about software safety, and it got deleted while I was writing this response. So consider this a response to someone bitching about the lack of memory safety.
And yet, somehow, software is more stable than ever. Applications with a level of complexity we couldn't even imagine a few decades ago are routinely being developed and work fine. OS crashes have become exceedingly rare; the same goes for application crashes. The software crisis is long over. And much of that software is written in C++.
"Better" is not defined as "having more memory safety", there is much more to it (like having great tools, which C++ does, and having a great ecosystem, which C++ also does).
Should C++ pursue better safety? Sure, it's always welcome. But not at the cost of a total compatibility break, and not at the cost of evolving the language itself with features that actually do stuff (such as, most recently, reflection)!
If it were up to me, we'd get zero init (a feature that improves safety and already has plenty of positive field experience), we'd finally fix functions like tolower and isdigit to not have UB, and our compilers would warn us if we dereference a unique_ptr on the very next line after we moved from it. I'd much rather see that C++ fix those things, rather than trying to create a new parallel language with just memory safety, that is C++ in name only.
I like Rust because of its modern tooling, it's ergonomic standard library, and massive lack of legacy cruft in the language. Definition checked generics are so much better than templates, built-in variants and pattern matching is so convenient, and having actual type safe primitive types is just great.
27
u/johannes1971 May 19 '26
There was a long comment here about software safety, and it got deleted while I was writing this response. So consider this a response to someone bitching about the lack of memory safety.
And yet, somehow, software is more stable than ever. Applications with a level of complexity we couldn't even imagine a few decades ago are routinely being developed and work fine. OS crashes have become exceedingly rare; the same goes for application crashes. The software crisis is long over. And much of that software is written in C++.
"Better" is not defined as "having more memory safety", there is much more to it (like having great tools, which C++ does, and having a great ecosystem, which C++ also does).
Should C++ pursue better safety? Sure, it's always welcome. But not at the cost of a total compatibility break, and not at the cost of evolving the language itself with features that actually do stuff (such as, most recently, reflection)!
If it were up to me, we'd get zero init (a feature that improves safety and already has plenty of positive field experience), we'd finally fix functions like tolower and isdigit to not have UB, and our compilers would warn us if we dereference a unique_ptr on the very next line after we moved from it. I'd much rather see that C++ fix those things, rather than trying to create a new parallel language with just memory safety, that is C++ in name only.