Majority goes to Rust for what it is developed for: system programming.
Just like I won't use Go for web app dev (ugh.. what a PITA)
Modern C++ is not memory safe, and there is no way for it to achieve memory safety without either significant runtime overhead or breaking compatibility so much it won't be C++ anymore. The features in modern C++ are nice, but they don't solve my problems.
Perhaps the driving force demanding memory safety isn't for one's own use, but rather the hope that the code one depends upon, written by other people, will get better. I.e., I write good code, and you write good code, but God forbid we have to rely on Microsoft, Google, Mozilla, and Red Hat monkeys to write good code! That's a legitimate desire, but it doesn't drive much personal adoption. Meanwhile, the PITA factor -- borrow checker not happy! "&" required! "&" forbidden! -- interferes with personal adoption of Rust.
And C++ keeps adding features. Not to fall increasingly behind, Rust needs to multiply its adoption rate. I don't see how that could happen. C++ is already good enough, so Rust can't cannibalize significantly from C++ coders. Rust is enough better than Go, Java, and C# to be worth a significant effort to switch, if users of those languages could perceive it. The greatest benefit to the world derives from driving people off C -- to Rust or modern C++, it matters little which.
I would use Rust in place of C++ or C in a heartbeat (and I would probably pick it over Go until they have generics), but I wouldn't use it in place of those other languages for the same reason I wouldn't use C++ in place of them. They're already managed, and I wouldn't have used them in the first place if I needed Rust's performance.
That's easy to answer. They do. Any look at a CVE list for a browser will confirm this. These browser engines are, by and large, written in a modern style.
> Are they now of mainly theoretical importance?
No.
At the same time, modern C++ also has advanced and valuable safety features that Rust does not have e.g. the enormous amount of compile-time verification and complex type construction that is possible. I find these to be far more valuable because the kind of bugs these catch are more common in practice. None of this is automatic but it is trivially enforceable as coding style, and many companies do.
The idea that C++ code bases are necessarily littered with memory safety bugs is nonsense. For people that have been writing this kind of code for a long time, avoiding those bugs is largely automatic and effortless. And you don't have to do violence to your data structures to achieve it. I can see an argument for someone coming into C++ from a language like Java but for experienced C++ programmers the value is dubious in practice.
There may be compelling technical reasons to use Rust over modern C++ but you'll have to do better than automatic memory safety, particularly given the safety and capabilities that would be sacrificed.
(I also disagree that modern C++ is safer than classic C++. Modern C++ adds more invisible ways to get use-after-free, which is pernicious.)
Rust can best grow its developer base by growing the number of new systems programmers, as they would have less to lose by using Rust and would be less likely to notice its limitations. The challenge here is that becoming a competent systems programmer is much more difficult than learning a new programming language, and there is a chronic shortage of developers interested in systems programming.
If we were still using classic C++ (i.e. C++03 and earlier) then I think Rust would have a real chance. The rapid evolution and adoption of modern C++ has fixed many (most?) of its major weaknesses.