Should C++ be deprecated?

That sounds like Rust's basic design philosophy - it's an opinionated language, and its opinions are sometimes not the traditionally popular ones.

E.g. it's "bad" at writing code that needs lots of raw pointers (like code that has complicated ownership but can't afford the run-time overhead of Rc+RefCell). The syntax is uglier than in C, the aliasing rules are more complicated and less clearly defined, performance may be worse (since Rust pointers don't have type-based strict aliasing), the documentation is full of scary warnings, the community will shun you for using too much `unsafe`, etc.

Programmers coming from C often want to write code that way. One of the first data structures they may try to implement is a linked list, which C is really good at and Rust is really bad at. But Rust is bad at that because Rust's designers would prefer you don't write code that way. They want there to be a significant amount of friction when using raw pointers, because you shouldn't be using raw pointers. It might upset those C programmers in the short term, but it's for their own good, and in the long term they'll come to appreciate it.

I think it would be entirely consistent with that philosophy for the language designers to decide that massive dependency trees are dangerous, no matter how much programmers from other languages seem to prefer working that way, and to design the language and tools in a way that makes that less convenient. Require Cargo.toml to have an explicit allowlist of the owners of all transitive dependencies, so developers are forced to be aware of how many random GitHub users they're trusting and are more attracted towards self-contained groups of crates with shared maintainership, or whatever. Don't do anything as accidentally terrible as C's build systems, but still do something to drive users towards what the language designers have decided is best practice, as they have with many other parts of the language.

In this case Rust didn't make that decision, but I think they could have (and maybe should have).

That sounds like: a "good" language ought to make using raw pointers a "bad "experience in order to force developers to do things the (memory-safe) way you would prefer instead of the (unsafe) way that they would prefer.

Could not resist sorry (and thanks to excors https://lwn.net/Articles/1038755/)

In this day and age of massive supply chain attacks, things like "cargo vet" are critical. I have no idea whether "cargo vet" is the best solution and I don't even have a strong opinion on "massive dependency trees". But for sure there has to be _some_ sort of SBOM constraints to force most developers not to do things the way they prefer, which is: let AI write some code that imports random, orphaned open-source libraries and go home sooner.

(I hope no one replies with "Just train, police and manage your developers" which is the "mythical workplace" argument)

I'd say the real driving force behind programming languages that tend to use lots of libraries is their package managers, not the language itself or the libraries. JavaScript, Cargo, and yes Python3 programs all tend to use a lot of libraries. But not Python 1.5 or the early versions of Python 2 that predate pip, and not C or C++.

They looked like a great idea at the time, but the supply side attacks package managers recursively resolving dependencies facilitate, I'm not sure if they aren't a curse rather than a blessing.