I don't claim that Rust is bulletproof. You still have to verify the axiomatic unsafe sections of your code. There can still be bugs in Rust itself, or logical errors in your programs. What I do claim is Rust is a giant leap forward over C++, which is an inadequate tool to write software end users will use. As society continues to rely more and more on software, as it becomes the thing that we stake our lives on, we have a moral responsibility to modernize our tools.
Rust is designed with the hindsight of C++ and many other languages, it frankly sweeps the floor in every way other than compile times and certain efficiencies, which will inevitably improve. The only legitimate reason to use C++ is to access legacy C++ libraries that Rust has not yet developed and maintain existing C++ projects.
That is not the only legitimate reason, at all; adoption of new technology takes time for good reasons. Rust is still pretty new, a lot of things are still only in nightly, and while impressive the ecosystem has a long way to go in terms of robust libraries.
Open source software is only one facet; there are plenty of companies with millions of lines of C++ internally, some of which making up parts of their infrastructure.
I'm being intentionally very non exhaustive for two reasons:
1, I don't feel I should have to explain this. It's self explanatory that these two extremely complicated things can't be compared like integers
2, because it's very much subjective. If you are starting a completely greenfield project Rust might be a good idea. I am a huge fan of what Rust has to offer. But it has it's kludges and kinks to work out, whereas companies have had decades to work out and improve their usage of C++. In particular, linting and coding standards for modern C++ projects generally go very far in improving memory safety even if they don't provide strong guarantees like Rust can. With enforced coding standards you can virtually eliminate risks like buffer overflow and discourage risks like data races. In addition to the ecosystem of libraries, there's a lot of excellent tooling for C++, for static analysis and debugging.
I fear now that I have elaborated the first instinct you will have is to poke holes in individual points. Please don't. All I'm trying to illustrate is that switching to Rust costs time+effort, and it is seriously not better than C++ in every way, in the same way that Go isn't.
There are also frameworks for C++ like Qt that mitigate data races by using an internal event loop and function scheduler to give concurrency guarantees.
Then we generally agree. Like I said, the one use case for C++ is if you're already using it, or require a library that is only available in C++.
My general point is that people should make a commitment to upgrade, and set a course in that direction. The opposite approach is the wait and see mentality, which leads companies waiting in perpetuity because they collectively never adopt better languages due to the sunk cost fallacy.
It's exactly the big companies that need to commit, because they have the resources to invest in sanding down the kludges and kinks and making Rust really better than C++ in every way, and it's in the early stages of Rust's development were senior C++ talent could really help set the direction of Rust based on what we've learned from C++.
C++ is updated every 3 years as an ISO standard. Rust is updated at the whim of the developers. C++ templates blow Rust's generics out of the water in terms of writing smaller code.
How does Rust sweep the flor in game engines like CryEngine or Unreal, GUI frameworks like WPF, Qt, MFC, IDE tooling like Visual Studio, database drivers like OCI and ADO, CUDA, Metal, DirectX....?
As a language Rust sleeps the floor with C++. You're mentioning a bunch of pieces of software, most of which is already written in C++ so you're giving me a kind of apples to oranges question.
Despite the ISO process being insanely difficult, I consider it and the people that make it happen C++ greatest strength. Will the creators of Rust and Go be as dedicated as Bjarne has with C++? Are they prepared to support and improve it for the rest of their lives? Oh wait, Gaydon is working on Swift now, sorry Rust people. Rob Pike also has a history of giving up and starting fresh, though he has been pretty dedicated to Go.
In other words, I'm confident if I write my code in C++ today, it will work in the next 30 years, while I can't say the same for Rust or Go.