OP is right, unfortunately. C++ is a dying language. Mozilla, Microsoft and Google are all looking at Rust. Why? Because it's probably makes more sense to rewrite a buggy C++ component in Rust instead of updating it to use modern C++ (where admittedly, you have to go out of your way to get things wrong). The damage has been done.
I'm also concerned about our ability to hire in the future. C++ devs will either be too expensive, or just not there since it's not an attractive language any more.
I'm not a Rustafarian either, I've actually never used it but it would be negligent of me to not look at it. One concern I have with it is that the eco-system may be full of poor-quality ports of C/C++ libs, because that's how people work when they learn a new language.
It's far too premature to declare its death. The pace of development of C++ is decently fast and there's many stakeholders with millions of lines of C++ who are interested in C++ not dying. C++ is taught in universities around the world so the chance of C++ developers becoming expensive is low.
To suggest C++ is a dying, slowing, or stagnant language is objectively delusional. The language is healthier than ever, and going gangbusters.
React Native, the new Games SDK for Android, WinUI 3.0 release, lifetime analysis support for Visual C++ and clang and lets not forget they are two major contributors to ISO C++.
While the Rust/WinRT efforts from Kenny Kerr are welcomed, that it is just yet another option alongside C#/WinRT, C++/WinRT, Python/WinRT and JavaScript/WinRT.
P.S. I'm not a COBOL programmer nor have I ever been a COBOL programmer.
Other than that it's nonsense to say that X is dying.
Sure, it'll stick around for some years yet but all those jobs will become maintenance jobs. Very little greenfield projects will elect to use it outside of niche areas (games and maybe embedded - UK salaries for embedded dev are terrible). Both C++ and Rust can use LLVM, so the generated code is likely to be the same.
If you were starting a greenfield project today why would you choose to do it in C++?
I forgot to mention Go too.
To suggest C++ usage is in decline is, objectively, nothing short of delusional. For Rust, C++ will the one to beat in ten and twenty years, provided not too many have already skipped onto some new hotness.
Rust is an objectively better design than anything else that has arisen in 30+ years. That doesn't guarantee success.
I used to hope a better language would displace C++, and for a time thought Rust might be it, but that better language turned out to be C++ itself. Nothing else is even on the horizon.
Oh and by the way, LLVM is 100% c++.
Saying it is too dangerous and complicated is absurd. It is easy to write safe code in C++, having been doing it for almost 30 years.
You are throwing around lots of assertions - challenge you to back them up with real data.
2. True, but growth curves are rarely linear. Here’s a rough proxy on users - the number of subscribers to /r/rust - https://subredditstats.com/r/Rust. Look at the growth between 2014-18 and 2018-2020. You’re extrapolating on current growth rate, but that may increase in future.
3. “Ambitious”. Nothing I’ve seen precludes using Rust for ambitious projects. In fact, seeing the experience of Dropbox, Mozilla, Facebook and others, there are some ambitious projects that could only have been done in Rust. I’m gonna say [citation needed].
I agree with Stroustrup and look forward to the day people complain about Rust :)
I'm guessing, but I think that something like Armadillo[1] would not be possible on stable Rust. Something like Catch[2] might also difficult to make ergonomic.
I don't program in C++ anymore and I would personally live with the lack of expression/abstraction for a safer language though.
[1] http://arma.sourceforge.net/speed.html [2] https://github.com/catchorg/Catch2/blob/master/docs/tutorial...
Also, how is it ergonomic? I'd agree if you say that it's (one of?) the best for C++, and it's also my go-to option, but ergonomic?
Type-aware macros might not be the best way to implement the features needed to match C++.
What about people not intimidated by C++ and want to switch to Rust anyway? Why have you discounted them? Do such people exist in your world view? Do you think there might be a good reason for those people to choose Rust?
There are kludgy workarounds for everything, more or less, but why switch to a limited language with immature tooling and practically nonexistent immediate prospects, when C++ demand is going up, up, and up?
Memory safety is just not an issue at the level where coders of modern C++ work. I have had exactly one lifetime error in five years, caught in initial testing. My bugs are overwhelmingly specification omissions and logic mistakes that Rust suffers from exactly as much.
My day-to-day experience is to write 2000 lines and, when it compiles, it works correctly, modulo a "!" short or extra. Then, I spend a few days refining the design, which often means deleting code. Things Rust promises to help with consume only trivial attention. Library features not expressible in Rust prevent many more and bigger problems.
Rust has some nice qualities I would rather C++ had--pattern match support, simple iterators, default const and default pass-by-move, sane conversions, sane initialization--but they are all low-level conveniences, not anything I am willing to trade away architectura-level capabilities for.
Rust is going interesting places, is taking full advantage of starting from scratch, and is miles ahead of C, Java, and Go on every axis. But if Rust could get to where C++ was in 2011 by 2025, that would be amazing. Meanwhile, C++ has already shipped C++14, C++17, and C++20, will have done C++23, and will be firming up C++26.
Assume Rust could match C++20, just five years later, in 2030, which would be more amazing. C++29 will be out.
The language is messy and filled with undefined behaviors and unsafe methods by default. Where there are rules you can mostly ignore them whenever you want. People complain about JavaScript being messy but C++ is way worse.
Though the language itself isn't all that bad, I don't understand why there so many build systems? And the top build system CMake isn't so much a build system as it is a build system for build systems that exists because no one can seem to agree on one.
Many of these systems seem bloated and over designed by comparison when I can install libraries or cross compile in one line in go. I couldn't help but think there had to be a better way and it seems like rust is that way. I expect C++ will eventually go the way of Cobol and eventually be used to maintain legacy systems.
p.s. thank God for vcpkg because I had nearly thrown in the towel while trying to integrate simple libraries until I discovered it.
Unfortunately for many people technology is still an emotional rather than a professional topic.
Nah, I mean maybe in the way that Fortran coexist with C/C++ for decades, but it's not equal coexistence.
I would rather say that new languages arise, replaces old ones for most scenarios and in the cases where they can't, due to various reasons, they push the old language into zombie state like cobol.
It's the same BS like NoSql will kill all R-D's.
You just don't invest millions just to rewrite programs that work's perfectly (and that's often the case with old battle-hardened software)
Deliberately inflammatory, and also false.
1. Rust has limited abstraction features to make it more approachable and implementable, but make it unable to express libraries that are easy in C++. This will not change soon, although Rust will accrete features at a steady rate. But the gap in feature sets will widen, not narrow with time.
2. The total number of people using Rust in production is easily less than the number who pick up C++ in any given week. It will be ten years before Rust is a mature industrial language, if it gets there. (It has made a good start in that direction, which is better than can be said for any other newish language.)
3. C++ and Rust will coexist for decades. The most ambitious work will continue to be done in C++, while Rust will be more than adequate for what might otherwise have been done in (the much less capable) C, Go, or Java.
4. D fizzled because it is too similar to C++, and therefore unnecessary. Rust found a ready audience in people intimidated by C++, frustrated with the limitations of C, Java, and Go, and ready to try something wholly new. Its designers have threaded the gap deftly, uniquely adopting C++'s greatest strength, the destructor (which it calls the "Drop trait"), and avoided weighing it down with garbage-collection. It has a bright future if it can multiply its adoption rate by two orders of magnitude.
As Stroustrup said, there are only two kinds of language: the ones people complain about, and the ones nobody uses.
With enough luck, by the time Rust is mature, it will have gained plenty to complain about. Rust will have got somewhere when you read more complaints about it than brags about having made it do something already done in a mature language.