New C++ code that your team has written, sure. What about all the libraries that you integrate with, that all have different models for allocating/using/freeing buffers? Or system APIs? (At best for those you can build a wrapper layer, and the wrapper layer is subject to the same errors as C/C++ classically is.)
One of the things that struck me as a major advantage about Java and garbage collected languages is that you can simply combine code from different libraries without worrying about what's freeing the objects, because that's the GC's job. With Rust, the memory management model takes over this responsibility without runtime cost (or minimal cost -- perhaps freeing something from the heap, if you allocated it there, but definitely not GC).
With C++, unless the library that you're using is using the same smart point library as you, from the same language version, then aren't you stuck writing wrappers around the libs you want to use?
Types like std::async seem to have changed in every recent revision of C++ version (11, 17, 20). Can you reliably find multiple open source libraries that you could integrate into a codebase that uses futures and async/await?
(It's been a long time since I've done much C++ professionally. I'm asking skeptically but genuinely.)
While true, I don't need to rewrite those libraries and can just use them rigth away, and this is why C++ keeps being my to-go language for native libraries, despite some of its flaws.
I can spend all my development budget on the problem instead sacrificing part of it to building an ecosystem.
Yeah, but that's a losing race. Considering how much investment is happening with Rust right now (when Amazon, Facebook, Google, Microsoft, a ton of smaller companies are investing), Rust will become "good enough™" at some point.
I'd imagine that we're at most 3 years away from it having mature libraries for 99% of tasks you'd want to do as a professional developer.
C++ has hardly replaced C in some domains after 40 years trying, and it is mostly compatible with C at source level, build exactly to fit into existing C toolchains.
Some of those companies, like Google, Microsoft and NVidia, are heavily invested into C++, ISO C++ and selling C++ based products.
To use a common example that one puts against any technology that Microsoft touches, when will Office use Rust on its foundation and extension APIs?
Are you aware that Apple has rather created their own safe C dialect for iBoot firmware instead of using Rust?
Sure, they end up looking similar, but the point is that with C++ the developer carries the burden of making sure everything is correct and doesn't prevent you or other developers from breaking outside the bounds of what is "good" - either on purpose, or accidentally, e.g. when refactoring.
With Rust, the burden of checking all of that is shifted to the compiler, and that reduces cognitive load for the developer.
Rust is not a panacea for all bugs, but making memory problems and data races a compile time problem rather than a runtime problem is a significant benefit.
Indeed, and if that is what makes the industry rediscover Ada and Modula-2, more the better, however care need to be taken how it is sold, and also be understood this is going to take several decades.
Anyone that cares about memory safety for userspace applications has already moved on into other languages, the problem is the foundation and those that resist no matter what.
Also the data races prevented by Rust type system only apply to multihreaded code accessing in-memory data structures, there plenty of other data races in multiprocessing scenarios.