Should C++ be deprecated?

Posted Sep 22, 2025 22:09 UTC (Mon) by marcH (subscriber, #57642)
In reply to: Should C++ be deprecated? by NYKevin
Parent article: Comparing Rust to Carbon

> But think about the implications of this for a moment. You would be arguing, essentially, that a "good" language ought to have a "bad" build system in order to force developers to do things the way you would prefer instead of the way that they would prefer.

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)

Should C++ be deprecated?

Posted Sep 23, 2025 8:11 UTC (Tue) by taladar (subscriber, #68407) [Link] (1 responses)

Your supply chain argument (whether through AI or otherwise) doesn't really work since a large dependency project with lots of committers is, if anything, more vulnerable to someone slipping in some random code in a place that none of the maintainers know very well, than a bunch of small dependencies.

As for unmaintained dependencies, that is what why we have the RUSTSEC announcements about unmaintained libraries along with cargo-deny or similar tooling. Of course our method of detecting when a dependency is unmaintained could be improved here but that is inherently still better than pretending a large dependency is maintained when really the code base is 50% maintained and 50% code nobody looked at for years.

Should C++ be deprecated?

Posted Sep 23, 2025 15:16 UTC (Tue) by marcH (subscriber, #57642) [Link]

Did you click reply on the wrong comment ? I reread my comment and I can't find anything looking like "approach A is more vulnerable to supply chain attack than B" (as you just affirmed without any substantiation)

I only wrote that supply chain attacks are intense and not treated seriously enough yet. IMHO, today's most important question is not where they are most likely to come from. It's what the best defense is. Ideally, that defense would be effective wherever they come from.

Should C++ be deprecated?

Posted Sep 23, 2025 15:53 UTC (Tue) by farnz (subscriber, #17727) [Link]

In terms of SBOM constraints and the Rust ecosystem, I see one essential tool, and two things competing for "long term direction".

The essential tool is cargo deny, which gives you three vital features (plus checking SPDX licensing tags):

You can block known vulnerable or unmaintained dependencies, so that you're not accidentally using something that's definitely bad, or that isn't being looked after.
You can ban specific dependencies, or certain versions of dependencies, so that you can stop people pulling in multiple libraries for the same task, or ban versions that you know don't work well with your codebase. This can be done as an allowlist of things you're letting in, or a denylist of things you do not want.
You can check that all dependencies come from a known-good source, rather than letting people point you at a random hosting site. This can also be used to prevent people pointing you at a random repo on a big hosting site like GitLab or BitBucket.

On top of that, you also want some functionality to at least let you distinguish "the code in this dependency has been audited by a trustworthy party" from "we're using this because it works, and we need to audit it before release". cargo vet does that with explicitly configured lists of trusted audits (and no transitive trust), cargo crev does that via a web of trust setup.

I have no particular bias towards either tool; both look like they could be made to work, and which one ends up preferred depends on details of what you're doing and how you determine who to trust.