Hard truth
Hard truth
Posted Sep 16, 2025 23:32 UTC (Tue) by pizza (subscriber, #46)In reply to: Hard truth by Wol
Parent article: Comparing Rust to Carbon
Uh... Rust is perfectly happy to call into non-safe things. And vice versa.
Posted Sep 17, 2025 0:28 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link] (42 responses)
But C++ is not Rust. C++ has a long tail of not-provably-safe legacy code to care about. If any call into such code were just as annoying as calling unsafe code from Rust, then C++ developers would quickly figure out how to turn off safety profiles and do so.
I'm not saying safety profiles are viable - like most sensible people who have looked at safety profiles, I think they're probably doomed. But I'm not sure there was ever a good alternative. The standards committee was really backed into a corner with this one.
Posted Sep 17, 2025 5:38 UTC (Wed)
by DemiMarie (subscriber, #164188)
[Link] (38 responses)
Posted Sep 17, 2025 7:11 UTC (Wed)
by viro (subscriber, #7872)
[Link] (29 responses)
You are presuming an authority that simply does not exist, neither in yourself, nor in anybody else.
Posted Sep 17, 2025 8:55 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (28 responses)
Posted Sep 17, 2025 9:40 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (26 responses)
The development of new product lines for use in service of critical infrastructure or NCFs (national critical functions) in a memory-unsafe language (e.g., C or C++) … is dangerous and significantly elevates risk to national security, national economic security, and national public health and safety.
– CISA, Product Security Bad Practices
Posted Sep 17, 2025 17:43 UTC (Wed)
by hmh (subscriber, #3838)
[Link] (25 responses)
Complain whatever you will about C and C++, but dependency hell is rare in the C and C++ ecosystems, often due to the use of one of the *few* popular includes-even-the-kitchen-sink frameworks, but those are well maintained and well gatekeeped (e.g. glib, Qt).
So, yeah, maybe C and C++ should be deprecated in general, but IMO dependency-hell should never be acceptable in any security-sensitive context, it is far worse a problem than the use of well-written C or C++.
Posted Sep 17, 2025 19:32 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link] (14 responses)
Posted Sep 18, 2025 13:52 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (13 responses)
If a language doesn't have a big standard library or a few well established kinda big libraries, you will inevitably end up with a lot of dependencies.
Posted Sep 19, 2025 3:52 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (12 responses)
What does that have to do with anything? None of C, C++, or Rust have big standard libraries. Well, I suppose you could make an argument for C++ being kinda big... but it's still a far cry from (e.g.) Python (and a fair amount of its functionality is also in Rust's stdlib).
> or a few well established kinda big libraries,
I contend that this is not a Rust problem, it is a "developers in general don't like big libraries" problem. Rust is perfectly capable of supporting large libraries. Developers choose not to produce or use them, because Cargo makes it relatively painless to produce and use small libraries instead. We see similar behavior in basically every programming environment whose build and packaging system makes it sufficiently convenient (Go, JavaScript, etc., but not Java, C, C++, etc.). In the case of Python, which has a deeply flawed but still sorta kinda mostly usable packaging system, we see a mixture of large and small libraries.
Now, you might argue that this does not matter either, that it's still a language with a lot of deps. 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. My broader point is that the market does not answer to you and your preferences. If you want big libraries, you can write them yourself, commission them from somebody else, or find an employer who uses a monorepo.
Posted Sep 19, 2025 11:02 UTC (Fri)
by excors (subscriber, #95769)
[Link] (1 responses)
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).
Posted Sep 19, 2025 12:25 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
This tames the "massive dependency tree" by requiring that you either audit your dependencies yourself (and publish an audits.toml that documents this audit), or that you import someone else's audit of your dependencies. It still allows people who don't care to have a massive dependency tree, of course.
Posted Sep 22, 2025 22:09 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (3 responses)
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)
Posted Sep 23, 2025 8:11 UTC (Tue)
by taladar (subscriber, #68407)
[Link] (1 responses)
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.
Posted Sep 23, 2025 15:16 UTC (Tue)
by marcH (subscriber, #57642)
[Link]
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.
Posted Sep 23, 2025 15:53 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
The essential tool is cargo deny, which gives you three vital features (plus checking SPDX licensing tags):
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.
Posted Oct 6, 2025 11:49 UTC (Mon)
by ras (subscriber, #33059)
[Link] (5 responses)
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.
Posted Oct 14, 2025 10:52 UTC (Tue)
by taladar (subscriber, #68407)
[Link] (4 responses)
Posted Oct 16, 2025 18:56 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (3 responses)
Do you have other examples?
Posted Oct 17, 2025 8:29 UTC (Fri)
by taladar (subscriber, #68407)
[Link] (2 responses)
The era of these kinds of supply chain attacks is only a few years old
I know e.g. Daniel Stenberg regularly talks in his blog about bugs that have been in the curl code base for a decade or more and that is a medium sized code base with relatively strict testing and oversight so I wouldn't be surprised if a vulnerability smuggled into something the size of Qt, LLVM or Chromium Embedded Framework with corners that haven't seen updates in years will only be discovered by 2040 by accident.
Posted Oct 17, 2025 8:43 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (1 responses)
Posted Oct 17, 2025 12:15 UTC (Fri)
by taladar (subscriber, #68407)
[Link]
Posted Sep 18, 2025 7:09 UTC (Thu)
by taladar (subscriber, #68407)
[Link] (9 responses)
Posted Sep 18, 2025 13:55 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (8 responses)
Posted Sep 18, 2025 15:11 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (7 responses)
What you care about is that each functional component you use is well-tested and easy to vet. If each functional component is in its own library, this is relatively simple; you can see the tests and the changes to the component, and confirm that you're happy about the way they're maintained.
With big libraries that bundle multiple functional components together (such as Qt, which has 12 "Essentials" and 47 "Add-ons" that make up Qt), it gets harder; the library as a whole may be well-tested and well maintained, but that's of no use to you if the bits you care about are untested and barely maintained beyond regular updates to reformat to current house style.
Smaller libraries tend to have fewer functional components to them; it's thus more likely that if you generalise from the state of the library as a whole to the state of the component you care about, you'll get it right. This is trivially true for libraries with a single component (the state of the library and the component are the same thing), and tends to remain true when they have a small number of interesting components.
And my experience is that people vetting that a library is well-tested and functional tend not to do deep-dives into sub-components; they will assume that Qt is a single thing, and therefore if Qt GUI is well-tested and good quality code, the chances are high that Qt CoAP is as good, despite the fact that they're separate components, and there's quite possibly no overlap between the engineers who work on Qt GUI and Qt CoAP.
Posted Sep 18, 2025 15:46 UTC (Thu)
by pizza (subscriber, #46)
[Link] (3 responses)
You're focusing solely on the technical side of things.
One's regulatory/compliance/etc burden grows linearly with the number of unique components, and the effort due to component complexity is usually dwarfed by a large fixed baseline overhead.
(As a perhaps example of this; $dayjob-1 required separate paperwork and mfg/batch tracking for each unique type/size of *screw*. Because when placed into a 3T magnetic field with >1MW gradient pulses... even a tiny screw will become a deadly projectile)
Posted Sep 18, 2025 16:18 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (2 responses)
You don't get to avoid doing the paperwork for each unique type/size of screw by saying "they're all from The Phillips Screw Company"; you have to do paperwork for each unique type/size anyway. Similar, IME, applies in software - just because it's all "Qt" doesn't mean that you can avoid doing the paperwork for each component you use.
Posted Sep 22, 2025 23:05 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (1 responses)
Not sure what the exact extend of "regulated spheres" is but here at $BIGCORP there is definitely some amount of per-supplier work. How could the compliance process not care about the supplier at all?
> You don't get to avoid doing the paperwork for each unique type/size of screw by saying "they're all from The Phillips Screw Company"; you have to do paperwork for each unique type/size anyway
You can at least copy/paste the supplier information, that's much less work that researching 100 different suppliers.
Posted Sep 23, 2025 8:18 UTC (Tue)
by farnz (subscriber, #17727)
[Link]
And 100 small libraries does not have to imply 100 suppliers - Qt, for example, is 59 libraries from one supplier. And because it's 59 libraries, instead of having to review all of Qt if we pull it into the regulated system, we only have to review the Qt libraries we use - maybe 2 or 3, instead of 59.
Posted Sep 19, 2025 0:51 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
- a large test suite
So you end up with things like coverage-based test selection, CI sharding, notification tules (CODEOWNERS), cache management, machine wrangling, etc. at the directory level instead of the project level where the forges tend to be *way* more focused.
Of course, if you want to add some piece to your software process, applying it to a single project repo is *way* easier than applying it to dozens of them. But I feel that software process upcycles are a slim margin in the overall churn a software project sees (whether monolithic or separate, monorepo or multirepo).
Posted Sep 19, 2025 10:42 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (1 responses)
As a downstream consumer, if I need to vet 10M lines of code (LOC), I need to vet 10M LOC; it doesn't particularly help me if those 10M LOC are in 2 libraries of 5M LOC each, nor does it help me if they're in 10,000 libraries of 1k LOC each. I still have to vet the lot, and confirm that all 10M LOC are tested to my standards (whatever those are).
My upstreams, however, benefit from splitting into smaller libraries, for all the reasons you state; it's rare for anyone to make a single change that affects all 10M LOC in one go, and thus you want to get all the gains of being in smaller libraries.
Qt is a great example here; it's split into many smaller pieces that are independent, precisely because of the pain you point out. That also means that if I use Qt in a project, I'm not auditing "one library", I'm auditing the N subsets of Qt that I use.
The bigger deal is sharing audits among groups; things like cargo vet and crev help with the technical side of this, but the social side is a much harder nut to crack.
Posted Sep 19, 2025 11:17 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
For some value of "independent", anyway.
While you can just grab the pieces you want (within limits), *updating* just the pieces that need new fun[ctions] and leaving the rest to their 10-year-old splendor ('cause that's when you vetted them, and if it ain't broken …) is not going to cut it. (Consider libboost as an extreme example of this.)
Of course, dependency heck isn't limited to Qt or Boost … but truly independent libraries tend to be more explicit about which versions of their dependencies they require than a more-or-less-explicit "get me whichever version of libfoo that was current as of 2025-09".
Posted Sep 17, 2025 14:04 UTC (Wed)
by nim-nim (subscriber, #34454)
[Link]
The whole point of creating “safer” C++ profiles/derivatives is to convince CEOs to pour more money into the C++ sink, because the proposal says new parts will be written in the “safe” derivative and the financier is strongly encouraged to believe that will eventually make the whole safe (eventually as when the pigs will fly but no one who wants to keep his job will say so openly).
Posted Sep 17, 2025 9:53 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (7 responses)
Inside a company, it's manageable, as long as you can get enough engineers who will do the same quality work or better in other languages - the mandate is "no new C++, or you get fired", and you're done.
But outside companies, you can't do that - how do you stop me writing code in private in C++? How do you stop me sharing C++ code with other people? How do you stop other people seeing my C++ code and reusing it?
If safety turns out to matter to people, I'd expect that C++ is on the Fortran road; it's not going to die out completely, but it's going to be less and less used outside of a few niches.
Posted Sep 17, 2025 10:11 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (2 responses)
If companies and governments start banning it, then Universities will stop teaching it.
If C++ featuring high on your CV is a turn-off rather than a turn-on, students won't choose to learn it.
Once that happens, programmers will stop writing personal C++ because they aren't using it as their main language at work.
And C++ will join the legacy languages such as Cobol and Fortran, where maintenance programmers are paid fortunes (we wish) to keep old code running.
Cheers,
Posted Sep 18, 2025 14:10 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (1 responses)
And Qt is just an example out of many.
Posted Sep 18, 2025 14:55 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
Frankly, Qt is an arcane and very-difficult-to-debug mess (and so is GTK). Proof: Just start about any nontrivial program in the console and watch the warnings scroll by.
That being said, bindings for Rust/Qt do exist. Assuming they're written well, they can go quite some way towards safe-ing your GUI code. You don't need to replace 100% of your code all at once, after all. A hundred 1%-sized steps work just as well.
Posted Sep 17, 2025 10:45 UTC (Wed)
by excors (subscriber, #95769)
[Link] (3 responses)
Anybody can say that, and you're always free to ignore them. It only really matters when the person saying it is a trusted expert and/or has some power over you. (If they're an expert, you can assume they've got good reasons for saying you shouldn't use that feature, and you don't need to waste time working through the whole rationale yourself to come to the same conclusion. If they have power, e.g. they can influence whether new compilers are going to be compatible with your old software, then their rationale doesn't matter and you should consider following their advice now to avoid some compatibility pain in the future. But you can still choose to ignore them, and accept the consequences.)
Standards bodies have both expertise and power, so it matters when they say something is deprecated. But things can also be deprecated by community consensus, or by a company's policies, or by an individual developer, etc. Any of them can say "we think you shouldn't use C++, and we're going to stop writing specifications/tools/documentation/etc for C++ and stop using C++ libraries in our applications and stop contributing to C++ projects", and it doesn't matter that not everyone will agree - it all contributes to a gradual shift away from C++.
Posted Sep 17, 2025 12:41 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (2 responses)
In the long run, things like the EU's Cyber Resilience Act are going to push in this sort of general direction, by stopping commercial entities from treating security as an externality, but that's a very slow process.
Posted Sep 17, 2025 16:26 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (1 responses)
Not necessarily. If the government entity responsible for the standards organization that certifies your certified-and-thus-expensive access control system, esp. its compliance with regulations and whatnot, says "C++ is deprecated", this directly translates to requiring extra justification/scrutinity when you renew said certification, the number of C++ experts who say that C++ is fine nonwithstanding.
Posted Sep 17, 2025 16:38 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
Ferrocene is an example of a qualified compiler; you'd use the Project Documents to determine whether you're meeting the qualification requirements for this compiler; in this case, there's a set of constraints in the Safety Manual which tell you what the caveats are for Ferrocene.
You might see the qualification caveats for your C++ compiler get gradually more stringent, which might have the effect of making you deprecate C++ (especially if they start to conflict with "custom and practice" in the wider C++ community), but that's the most certification is likely to lead to.
Posted Sep 17, 2025 6:50 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
Then could you have weak and strong profiles - preferably with a pragma that says which applies to which module?
So a weak pragma will simply check that module, and say "this code does nothing silly, can't vouch for what it calls". A strong pragma would be your Java checked exception - "this code does nothing silly, nor do the routines it calls".
It would take a long time to percolate through, but then places could have a policy that every time you modify code, you apply the weak pragma, make that work, and then see if the strong pragma works too. So it's basically niggling you forward one module at a time?
Cheers,
Posted Sep 18, 2025 1:55 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
First, one needs to migrate to modules for this to be applicable.
Posted Sep 17, 2025 9:41 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
You'd have a special type of block that goes around items, that says that everything inside this block, including imported modules, can be used from safe code without an annotation at the point of use, even though it's not checked and safe. Because it covers everything inside the block, it covers everything brought in by a #include; because it's a special type of block with its own marker, it's possible to write tooling around the use of these blocks that requires review by senior developers.
Hard truth
Should C++ be deprecated?
Should C++ be deprecated?
Should C++ be deprecated?
That doesn't mean that anybody is forced to rewrite anything. Deprecated software (and hardware) can and does live on for ages.
However if you ever need to change more than three lines of that code, that deprecation tag does help when managers insist on putting yet another band-aid on that aging library instead of rewriting it in something sane – which, more often than not, will save a heap of time in the long run.
Should C++ be deprecated?
Should C++ be deprecated?
Should C++ be deprecated?
Should C++ be deprecated?
Should C++ be deprecated?
Should C++ be deprecated?
Arguably, that's what tools like cargo vet are for. An interested organisation (say Debian, or the FSF, or Google, or CENELEC) can set up a URL that lets you grab their current approved list of dependencies, along with their audit criteria, and then tell you things like "if you want this to be in the main archive, you need to meet 'debian-main' criteria for dependencies" or "we require that new dependencies for the Chrome build system meet our 'safe-to-deploy' audit criteria".
Forcing reduced size dependency trees
Should C++ be deprecated?
Should C++ be deprecated?
Should C++ be deprecated?
In terms of SBOM constraints and the Rust ecosystem, I see one essential tool, and two things competing for "long term direction".
Should C++ be deprecated?
Should C++ be deprecated?
Should C++ be deprecated?
Should C++ be deprecated?
Should C++ be deprecated?
Should C++ be deprecated?
Should C++ be deprecated?
Should C++ be deprecated?
Should C++ be deprecated?
Fewer libraries in use does not imply better tested or easier to vet - IME, it's quite the opposite.
Should C++ be deprecated?
Should C++ be deprecated?
IME, regulated spheres don't care whether you get 100 functional components from one library, or whether you use 100 libraries each with one component - they want you to do the compliance burden for each component you use, not for each supplier.
Should C++ be deprecated?
Should C++ be deprecated?
For some regulated processes, the compliance process does not care about the supplier at all. Instead, we have to show that every line of code available to the build system is (a) approved by a named employee of the company using the code, and (b) that there is a process to ensure that no changes are made to that code without a named employee of the company using the code approving it. This implies that when we update a dependency, we're having to take a diff between the two versions, and audit the changes line-by-line as well as in context, just as you do for new code from within the company.
Should C++ be deprecated?
Should C++ be deprecated?
- that takes a long time to run
- lots of interconnected bits, so a small change can affect oodles of tests
- desire to sequence contributions without completely linearizing them (merge trains)
How you perceive that depends on where in the chain you are, too.
Large libraries versus small ones
Large libraries versus small ones
Should C++ be deprecated?
How do you deprecate C++, though?
Should C++ be deprecated?
Should C++ be deprecated?
Wol
Should C++ be deprecated?
Should C++ be deprecated?
Should C++ be deprecated?
But to deprecate C++ globally means getting most of the trusted experts worldwide to say that C++ is deprecated; I don't see a path through to that in the near future, because the people we'd need to deprecate C++ in any significant fashion are currently backing C++.
Should C++ be deprecated?
Should C++ be deprecated?
Most of the standards I'm aware of don't care about language in use - they won't ever deprecate C++ as a result. Instead, they have the notion of a "qualified compiler", and if your compiler is qualified and you meet the caveats of that qualification, then you can do your certification at source level, instead of binary level.
Should C++ be deprecated?
Hard truth
Wol
Hard truth
There is a solution to that which has already been rejected, unfortunately, since it also acts as "add an annotation to make it possible to make a call to legacy code".
Hard truth