|
While I'm glad to see C++ improve, and I'm happy that Rust seemed to influence this, I don't think that it will kill either Rust or C++. As you say, there's a ton of C++ code out there. However, five things: 1. A _lot_ of that is C++98.
2. These rules are just proposed. There's tons of time.
3. They don't give you as much safety as Rust.
4. Many people have already rejected C++.
5. Langauges don't die.
So, one and two are kind of related. We're still in the "propose" stage for all of this, which means there are still years before this would make its way into the standard. How long have things like modules taken? Who knows when the rules will be final, and when they'll actually land. You get all of this (and more) in Rust right now.As for three, while these rules help, and are laudable, they still don't give you data race freedom. In general, they're not intended to be an ironclad safety system, just something to help catch more cases where something went wrong. See Herb's insistence that pointers should be able to dangle in some circumstances, as an example. I saw a comment on Reddit that straddles three and four, here it is: https://www.reddit.com/r/programming/comments/3m6j2c/cppcon_... > Just follow this set of hundreds of rules (seriously, go read the core
> guidelines), ignore 20 years of material written about C++ before the
> year 2011, use this non-standard third-party library of stuff we
> really like, and you too can have a fraction of Rust's compile safety.
This is phrased a little to sarcastically imho, but there's a nugget of truth there. One of C++'s problems is that it's just got too many features, bolted on over decades. Is bolting on yet another feature the way forward? How much of that existing C++ code will even be able to take advantage of these new safety features?A lot of people have already rejected C++, for various reasons. The details of those reasons are varied, and may be good reasons or bad reasons, but the point is, they've already said nope. A lot of people coming to Rust fit in this category. "I tried C++ one time, but it's too complex." "I can write some basic C++, but I'm not confident my code is correct." "I write Ruby code, C++ looks terrifying, and I hear it's hard never tried it." And so on. Our industry is huge, there are a lot of developers, and not all of them will use a single language even if it's 'better.' That cuts both ways. And ties into five. I don't think the question "Will Rust kill C++" is well formed. A language that's used as much as C++ is will never die. We'll have C++ code in production for at least my lifetime, I'd bet. Rust doesn't need for C++ to go away. Languages aren't the Highlander, there can (and often are) more than one. I mean, look at Python and Ruby. They're really similar languages from a PLT perspective, but they're both active, healthy, used-by-millions languages, and many of their programmers wouldn't switch to the other. This is totally fine. |
If anything, please take my point of view of someone that cannot ever use Rust until the customers say I am allowed to.
On my type of work we only use first class languages, those that are provided as part of whatever platform we are targeting.
This is my point of view of "worse is better".
Many might have rejected C++ or C (e.g. I don't like C at all), but many more are on the same boat as I.
For us system programming means C++ and C, until the IT department or customer allows anything else on our dev machines.