People are making arguments here about whether it's legacy based on number of projects in C++ or # developers who know C++, and that's just wrong. It's unnecessarily conceding the argument that we can't compare languages on the merits, which we can.
Cobol is legacy compared with C++, when C++ was new. You can see it immediately, the new language is just better than the old one, the writing is on the wall. All of the arguments for C++ boil down to path dependence ("We have X million lines in it", "obscure platform X isn't supported by clang", etc) there aren't good arguments for a new project to pick C++ over Rust.
So it's legacy because Rust dominates C++. It will take time for that to play out and for the amount of code in rust to exceed the amount written in C++, but it's true.
(There's an additional argument one might make that Rust is a niche language that won't gain traction, but we're far past the point where that argument can be taken seriously, with Rust in the Linux kernel, and Amazon, Google and Microsoft all adopting it)
While I praise Rust's security, there are dozen of use cases where C++ rules and Rust hardly has an option that can match C++'s offerings in libraries, IDE tooling, job offers, platform support, unless one is into creating ecosystems from scratch mood.
C++ is still the de facto language to write truly performance-oriented programs. While I do find Rust refreshing in that it actually brings something novel to the PL space, let’s not put the horse before the cart. While I’m optimistic about Rust’s future, it is still a tiny niche language compared to bigger ones, especially C++ in their targeted niche.
Cpp is the de facto language for that, it’s not that it is impossible to do so in rust. But there are certain patterns not as well expressible in rust.
> People are making arguments here about whether it's legacy based on number of projects in C++ or # developers who know C++, and that's just wrong.
They are hype-driven cargo-cultists who embody the role of hype-driven fanboys mindlessly pushing a hyped technology.
No technical merit is presented other than cargo-cult aspirations, and to fill in the void in their rationale they resort to try to denigrate other technologies again through non-technical arguments.
The most pressing problem plaguing Rust is it's community and it's extensive use of ignorant and/or bad faith claims to upsell Rust while criticising technologies they know nothing about. Most of the people they are trying to pull these stunts are professional software developers with years of experience. Perhaps some of them know a thing or two about the technologies they've been using? Why does the Rust community think these stunts work in their favour?
> No technical merit is presented other than cargo-cult aspirations, and to fill in the void in their rationale they resort to try to denigrate other technologies again through non-technical arguments.
I don't even believe you think this is true. People who recommended Rust are generally positive.
Sure, sometimes it's compared to other languages and ecosystems, but that's usually done to point out improvements it has over other languages people are familiar with (I think that's just to describe).
For example, I could talk in a void how I like that the packaging and build system are more cohesive and simple, but it will be a long essay as to why, and ring differently to different audiences. An TypeScript, Ruby and Python developer will not be interested, since they've always had those. But comparing it to C/C++ build systems makes more sense, because the languages occupy the same domain.
There's other examples I could give with regards to the type system, etc. So, it's not there for me to tell you "why C++ sucks" but to easier demonstrate to you what improvements would make your job easier and more enjoyable. Some people disagree, and you do too, and that's fine.
If you say you disagreed because X, people will respond, though. They will either think you're trying to misconstruct the narrative (like I feel you did in this comment, but I apologise if that's not true), or think you have a misunderstanding or a misconception and want to clarify what they said. So, it's not an attack, it's just Internet comment etiquette.
The point was never to put C/C++ down, just to make it easier to illustrate the improvements. People have always complaining and disliked the accidentally complexity of C++; it's got nothing to do with Rust. The only difference now is that there's an alternative.
Or another thing, which could be purely anecdotal: I've worked on C++ codebases and Rust codebases both in private and professionally, and even though I have more experience with C++, I'm generally more confident when working with Rust. Probably because I'm less "vigilant" of certain types of bugs due to the more modern type system.
None of this is to say that Rust doesn't have its own problems, because it certainly does
Maybe because the Rust community care about the language, develop it openly, in cooperation with like-minded people, want to be inclusive and care about software security? Of All these, what does the C++ standard committee do?
No surprise why Rust people can be ( sometimes) sound like cult, where it's just a community.
Cobol is legacy compared with C++, when C++ was new. You can see it immediately, the new language is just better than the old one, the writing is on the wall. All of the arguments for C++ boil down to path dependence ("We have X million lines in it", "obscure platform X isn't supported by clang", etc) there aren't good arguments for a new project to pick C++ over Rust.
So it's legacy because Rust dominates C++. It will take time for that to play out and for the amount of code in rust to exceed the amount written in C++, but it's true.
(There's an additional argument one might make that Rust is a niche language that won't gain traction, but we're far past the point where that argument can be taken seriously, with Rust in the Linux kernel, and Amazon, Google and Microsoft all adopting it)