However Rust is single vendor and single implementation, has a much smaller community and ecosystem than C++, is not standardized, and does not support all of the platforms and use cases that C++ does.
All of those problems are long-term solved by using more Rust, whereas none of C++'s problems are long-term solved by using more C++.
(Personally, I don't find single-vendor or lack of standardization a problem in practice, and I've never written C++ for a platform Rust doesn't support.)
I'm not sure that's true. Giving C++ 30 years has resulted in the things identified in the article. (In particular, giving auto_ptr 20+ years hasn't resulted in anything that really fixes the problem.) It is not clear to me that it's moving in the right direction, so I don't think more time will help. C++ is definitely ahead in popularity but is neither ahead not obviously aimed in the right direction in safety.
Giving Rust about ten years has resulted in significant growth in popularity and tooling, including attempts to write new implementations of the language (e.g., mrustc), so given more time and in particular given more production users, it seems reasonable to expect it will figure all those things out.
Except for stuff like "trusting trust", I find no need for "multiple vendors of Rust toolchains". It only comes handy when the language itself is not truly open source, and is in itself a form of a product.
Building on that " is not standardized," is not a problem, because one Open Source implementation is de facto the standard. Which I find much better than forever fixing your code, working around incompatibilities, bugs, etc. in compilers from different versions.
Which leaves "does not support all of the platforms and use cases that C++ does" which is indeed true.
Sometimes different vendors provide some benefits. For example Intel's C++ compiler produces (or used to produce?) much more efficient numerical code than either gcc or clang.
So for numerical applications C++ may make more sense than Rust. Rust does have the advantage of being based on an LLVM backend. So perhaps different vendors can compete by writing more efficient backends that are applicable to both C++ and Rust (but you probably lose some information when skipping the compiler front end)
> For example Intel's C++ compiler produces (or used to produce?) much more efficient numerical code than either gcc or clang.
I'm not an expert, but I believe that Intel could have implemented their hardware-specific optimizations in any other compiler framework (either gcc or clang). In this case multiple language implementations, while commercially viable, are not beneficial to all users.
But a community and an ecosystem can be built over time (and are being built for Rust incredibly rapidly). Whereas a problematic language can't really be "fixed", it can only be added to.
That’s very true. But all of those communities, ecosystems, standards, and use cases have an extreme learning curve and a very deep problem with security. :-)
It's a bona fide C++ killer for applications that are both security and performance critical. It's already gaining traction for those applications even within relatively conservative engineering organisations.
That said, there are many performance-critical applications who are not security-critical, and in those I'd expect C/C++ to persist pretty much indefinitely. And many security-critical applications which are not performance-critical, and can perfectly well be served by garbage collected languages like Java/C#/Go.
Cargo is the problem for those organizations. People who worry about security and safety often develop on airgapped networks. You can go nostd for small stuff. For bigger stuff you could mirror crates.io but that isn't a well supported workflow and it's a lot o code from a lot of randos. The notion of a blessed subset would help get more buy in from that community. Even still, rustup isn't working on airgapped Dev nets and it's a nice feature especially if you are crosscompiling.
C++ has a huge learning curve too though, the difference is it lets you write whatever you want. The learning curve is to write correct C++. It’s deceptive, it’s like skiing vs snowboarding. Skiing you pick up fast but to get good is damn hard and few bother. Snowboarding is damn hard to pick up but then it’s pretty easy to become really good.
To modify this I'd say that becoming reasonably good is pretty easy (and I'd agree easier than skiing). To be become really good takes a long time and a lot of dedication and the difference in difficulty between skiing and snowboarding disappears. Same as with programming, some languages make it easier to go from 0 to your first app, some make it easier to write solid production ready code that earns you a paycheck, but becoming really good is always hard and independent of the language you're using.
> Rust's learning curve isn't exactly a shallow one either.
I don't know how people can be so sure of this. We know essentially nothing about how to teach or learn Rust effectively, it's something that the community is just starting to look at. However, one thing we do know is that the detailed support that the Rust compiler provides to the novice programmer is quite simply unparalleled in other mainstream languages. It's basically the ultimate T.A.
I’m not sure I’d use as strong language as you (though I personally love the rust compiler’s messages), but I will say it’s gotta count that it doesn’t automatically and silently generate instance methods that explicitly break the memory model (cough rule of three…)
(Personally, I don't find single-vendor or lack of standardization a problem in practice, and I've never written C++ for a platform Rust doesn't support.)