Hard truth [LWN.net]

Hard truth

Posted Sep 16, 2025 22:21 UTC (Tue) by willy (subscriber, #9762)
In reply to: Hard truth by jbills
Parent article: Comparing Rust to Carbon

Relevant opinion: https://www.theregister.com/2025/09/16/safe_c_proposal_di...

to post comments

Hard truth

Posted Sep 16, 2025 22:39 UTC (Tue) by Wol (subscriber, #4433) [Link] (52 responses)

Apparently the C++ guys don't want memory-safe functions to be only allowed to call other memory-safe functions. Which is absolutely fundamental to Rust.

But isn't that just a fundamental requirement of safety? Aiui, the biggest problem with profiles, is that if you mix code combining different profiles, you lose the guarantees that profiles are meant to provide!?

So unless you say "there's only one profile", profiles don't work. So the STL will be forced to dictate a single profile. Which means all other programs will have to use the same profile. Which promptly means the C++ guys will - in practice - be banning safe functions from calling non-safe ones ... exactly what they say they *don't* want to do.

Cheers,
Wol

Hard truth

Posted Sep 16, 2025 23:32 UTC (Tue) by pizza (subscriber, #46) [Link] (49 responses)

> Apparently the C++ guys don't want memory-safe functions to be only allowed to call other memory-safe functions. Which is absolutely fundamental to Rust.

Uh... Rust is perfectly happy to call into non-safe things. And vice versa.

Hard truth

Posted Sep 17, 2025 0:28 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (48 responses)

If we're a bit charitable, I think the point is that calling an unsafe function from a safe function is almost (but not quite) as annoying as calling a Java function that throws a checked exception. This is, of course, intentional - you're not supposed to call unsafe functions if you can reasonably avoid it, and Rust tones down the annoyance just enough to make it bearable in cases where you really do need unsafe.

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.

Should C++ be deprecated?

Posted Sep 17, 2025 5:38 UTC (Wed) by DemiMarie (subscriber, #164188) [Link] (44 responses)

I wonder if it is time to outright deprecate C++ and tell people they need to rewrite their code. Yes, it will be a giant mountain of work, but it’s the only pure-software solution I know of. CHERI can solve memory unsafety in hardware, but that hardware isn’t available yet.

Should C++ be deprecated?

Posted Sep 17, 2025 7:11 UTC (Wed) by viro (subscriber, #7872) [Link] (32 responses)

Re telling people that they need to do arseloads of work on your say-so: "I can call spirits from the vasty deep". Remember the response to that?

You are presuming an authority that simply does not exist, neither in yourself, nor in anybody else.

Should C++ be deprecated?

Posted Sep 17, 2025 8:55 UTC (Wed) by smurf (subscriber, #17840) [Link] (31 responses)

Let's face it, C and C++ are not memory safe and cannot be convinced to become so. So yes they should 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?

Posted Sep 17, 2025 9:40 UTC (Wed) by smurf (subscriber, #17840) [Link] (29 responses)

In any case. it already has been deprecated by a variety of people and organizations, e.g. CISA:

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

Should C++ be deprecated?

Posted Sep 17, 2025 17:43 UTC (Wed) by hmh (subscriber, #3838) [Link] (28 responses)

But what CISA has to say about languages where almost always one ends up with large dependency sets and a massive SBOM?

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++.

Should C++ be deprecated?

Posted Sep 17, 2025 19:32 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (17 responses)

Rust does not force the use of huge dependencies. It does not even force you to have a memory allocator. The huge deps exist because developers (and by extension, their users and other stakeholders) like the benefits of those deps and choose to take them rather than reinventing the wheel.

Should C++ be deprecated?

Posted Sep 18, 2025 13:52 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (16 responses)

This is kinda meaningless.

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.

Should C++ be deprecated?

Posted Sep 19, 2025 3:52 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (15 responses)

> If a language doesn't have a big standard library

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.

Should C++ be deprecated?

Posted Sep 19, 2025 11:02 UTC (Fri) by excors (subscriber, #95769) [Link] (1 responses)

> 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 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).

Forcing reduced size dependency trees

Posted Sep 19, 2025 12:25 UTC (Fri) by farnz (subscriber, #17727) [Link]

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".

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.

Should C++ be deprecated?

Posted Sep 22, 2025 22:09 UTC (Mon) by marcH (subscriber, #57642) [Link] (3 responses)

> 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.

Should C++ be deprecated?

Posted Oct 6, 2025 11:49 UTC (Mon) by ras (subscriber, #33059) [Link] (8 responses)

> Developers choose not to produce or use them, because Cargo makes it relatively painless to produce and use small libraries instead.

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.

Should C++ be deprecated?

Posted Oct 14, 2025 10:52 UTC (Tue) by taladar (subscriber, #68407) [Link] (7 responses)

I would argue that supply side attacks are much easier to run on huge projects that have dozens of developers that don't even all know each other and that half consist of code nobody looked at for the last 5 years.

Should C++ be deprecated?

Posted Oct 16, 2025 18:56 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (6 responses)

The xz thing happened on a rather small dependency. The weekly disaster that happens on npm/pypi are usually on tiny things.

Do you have other examples?

Should C++ be deprecated?

Posted Oct 17, 2025 8:29 UTC (Fri) by taladar (subscriber, #68407) [Link] (5 responses)

Do languages with large dependencies even have the tooling to find these?

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.

Should C++ be deprecated?

Posted Oct 17, 2025 8:43 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (4 responses)

We're talking about supply chain attacks, not bugs. Do you have relevant examples or not?

Should C++ be deprecated?

Posted Oct 17, 2025 12:15 UTC (Fri) by taladar (subscriber, #68407) [Link] (3 responses)

My entire point is that nobody looks at those code bases so we simply don't know. Meanwhile the languages with small dependencies actually develop tooling to make those problems visible.

Should C++ be deprecated?

Posted Oct 19, 2025 6:13 UTC (Sun) by LtWorf (subscriber, #124958) [Link] (2 responses)

The Russel teapot principle of supply chain attacks…

Should C++ be deprecated?

Posted Oct 20, 2025 7:33 UTC (Mon) by taladar (subscriber, #68407) [Link] (1 responses)

Once you see your e.g. Qt bugs migrated to the third bug tracker in a decade without even getting a response you do tend to get a bit jaded about the claim that large libraries of that kind are "maintained".

Should C++ be deprecated?

Posted Oct 20, 2025 14:37 UTC (Mon) by smurf (subscriber, #17840) [Link]

Consider yourself lucky if the bug stays open and isn't auto-closed after two releases. No you can't re-open the beast, just open a new one. No you didn't get notified to check whether the problem is solved, that'd be too easy.

Affected (or rather affecting) projects shall not be named here. You know who you are.

Should C++ be deprecated?

Posted Sep 18, 2025 7:09 UTC (Thu) by taladar (subscriber, #68407) [Link] (9 responses)

Lets be honest. Numbers of dependencies are just smaller while individual dependencies are often huge in C and C++ because their build systems make it painful to create new projects and to include many projects, not because it is a good idea to put everything into one huge dependency.

Should C++ be deprecated?

Posted Sep 18, 2025 13:55 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (8 responses)

You are right that it's why there are fewer libraries in use. The end result though is that there are fewer libraries in use, which tend to be more well known and tested and are easier to vet.

Should C++ be deprecated?

Posted Sep 18, 2025 15:11 UTC (Thu) by farnz (subscriber, #17727) [Link] (7 responses)

Fewer libraries in use does not imply better tested or easier to vet - IME, it's quite the opposite.

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.

Should C++ be deprecated?

Posted Sep 18, 2025 15:46 UTC (Thu) by pizza (subscriber, #46) [Link] (3 responses)

> What you care about is that each functional component you use is well-tested and easy to vet.

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)

Should C++ be deprecated?

Posted Sep 18, 2025 16:18 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

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.

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.

Should C++ be deprecated?

Posted Sep 22, 2025 23:05 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)

> 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.

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.

Should C++ be deprecated?

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

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.

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.

Should C++ be deprecated?

Posted Sep 19, 2025 0:51 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

Another thing is that larger projects require non-linearly larger software process and infrastructure. Testing a focused 1k line library is fairly trivial. Testing 10 of them is still reasonable. On the other hand, figuring out testing for multi-million-line projects is a completely separate endeavour because you have, all at once:

- a large test suite
- 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)

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).

Large libraries versus small ones

Posted Sep 19, 2025 10:42 UTC (Fri) by farnz (subscriber, #17727) [Link] (1 responses)

How you perceive that depends on where in the chain you are, too.

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.

Large libraries versus small ones

Posted Sep 19, 2025 11:17 UTC (Fri) by smurf (subscriber, #17840) [Link]

> Qt is a great example here; it's split into many smaller pieces that are independent

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".

Should C++ be deprecated?

Posted Sep 17, 2025 14:04 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

That does mean that when organisations weight new software investments they are less likely to reinvest in old C++ codebases.

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).

Should C++ be deprecated?

Posted Sep 17, 2025 9:53 UTC (Wed) by farnz (subscriber, #17727) [Link] (10 responses)

How do you deprecate C++, though?

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.

Should C++ be deprecated?

Posted Sep 17, 2025 10:11 UTC (Wed) by Wol (subscriber, #4433) [Link] (3 responses)

> How do you deprecate C++, though?

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,
Wol

Should C++ be deprecated?

Posted Sep 18, 2025 14:10 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (1 responses)

Do you have any good replacement for Qt then? Because until you do I don't think that's going to happen.

And Qt is just an example out of many.

Should C++ be deprecated?

Posted Sep 18, 2025 14:55 UTC (Thu) by smurf (subscriber, #17840) [Link]

https://blog.logrocket.com/state-rust-gui-libraries/ lists 11 GUI libraries … presumably one of them will serve whatever your particular usecase is.

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.

Should C++ be deprecated?

Posted Feb 5, 2026 22:24 UTC (Thu) by popasmuerf (guest, #182197) [Link]

Universities switched their Computer Science programs from C++ to Java over 20 years ago in the late 90s and the early 00s, and if you think they will stop offering courses in C++ entirely you are a fool given that C++ is a prime mover in many niches (High Performance Computing) where the use case requires the performance and fine grained control that you can only get with what amounts to portable assembly.

Rust isn't going to replace C++ my guy...not now...not ever...for several reasons.

Should C++ be deprecated?

Posted Sep 17, 2025 10:45 UTC (Wed) by excors (subscriber, #95769) [Link] (5 responses)

Deprecating doesn't mean banning. It means saying "we think you shouldn't use this, and we're probably going to put less effort into supporting this in the future".

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++.

Should C++ be deprecated?

Posted Sep 17, 2025 12:41 UTC (Wed) by farnz (subscriber, #17727) [Link] (2 responses)

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++.

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.

Should C++ be deprecated?

Posted Sep 17, 2025 16:26 UTC (Wed) by smurf (subscriber, #17840) [Link] (1 responses)

> to deprecate C++ globally means getting most of the trusted experts worldwide to say that C++ is deprecated

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.

Should C++ be deprecated?

Posted Sep 17, 2025 16:38 UTC (Wed) by farnz (subscriber, #17727) [Link]

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.

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.

Should C++ be deprecated?

Posted Feb 5, 2026 22:24 UTC (Thu) by popasmuerf (guest, #182197) [Link] (1 responses)

I really don't get this ridiculous idea that one of the major programming languages that has no peer with respect to modern HPC is in any way going to be "deprecated".

There are next to no real industry demand for Rust statistically speaking that is worth mentioning (hence the reason you don't see a hiring rush for Rust programmers outside of Crypto) but somehow C++ is going to be "depricated" for a programming language that no one outside of people yapping on social media about ?

Will Rust grow and become more popular ? Yes...I think it will...but within it's niche...which is basically use cases that typically called for Ada, not C/C++

Should C++ be deprecated?

Posted Feb 6, 2026 11:13 UTC (Fri) by smurf (subscriber, #17840) [Link]

The "niche" for Rust isn't just Ada and its (not "it's", dammit) safety features. It's realizing that using Rust leads to (un)surprisingly large productivity gains – despite the somewhat-intimidating learning curve. Just ask Google. Or the Asahi Linux people.

Hard truth

Posted Sep 17, 2025 6:50 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

Umm ...

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,
Wol

Hard truth

Posted Sep 18, 2025 1:55 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

> So it's basically niggling you forward one module at a time?

First, one needs to migrate to modules for this to be applicable.

Hard truth

Posted Sep 17, 2025 9:41 UTC (Wed) by farnz (subscriber, #17727) [Link]

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".

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

Posted Sep 17, 2025 8:24 UTC (Wed) by danielthompson (subscriber, #97243) [Link] (1 responses)

> Apparently the C++ guys don't want memory-safe functions to be only
> allowed to call other memory-safe functions. Which is absolutely
> fundamental to Rust.

Curiously Rust moved even further on this for the 2024 edition: it is no longer assumed that unsafe functions should have unsafe bodies. At this point it is only an on-by-default warning but even within an unsafe function then the tools now strongly encourage the use of the unsafe keyword before accessing the superpowers.

https://doc.rust-lang.org/nightly/rustc/lints/listing/all...

Hard truth

Posted Sep 17, 2025 22:55 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

This is because it never made much semantic sense to allow unsafe functions to do unsafe things in their bodies in the first place. The unsafe keyword has two entirely different meanings:

- As a specifier on the function signature, it is part of the API, and signals that the function has nontrivial safety preconditions which are not enforced by the compiler. By convention, these preconditions are listed in the function's doc comment under the "Safety" header.
- As a block of code, it represents an acknowledgement that one or more operations inside of that block have safety preconditions which are not enforced, and a promise by the developer to uphold those preconditions manually. By convention, the block is commented with a SAFETY comment explaining why the applicable preconditions hold at that point in execution.

Because the compiler does not know what precondition the programmer is promising to uphold with any given unsafe block, nor the exact preconditions any given unsafe function or other unsafe operation* might require, it has no way of checking one against the other. It is therefore not unheard of for programmers to deliberately make all unsafe blocks as small as possible. If only one operation is wrapped in unsafe, then you only have to worry about the preconditions of that one operation, and will not accidentally make unrelated promises about constructs you wrongly believed were safe. Fortunately, Rust treats unsafe blocks (and blocks in general) as expressions, so you can pinpoint the unsafe operation you want to allow and leave the rest of the expression in safe code, if you so desire.

By allowing unsafe functions to do unsafe things in their bodies without a separate unsafe block, older Rust editions inappropriately conflated these two meanings. More importantly, they made it much harder to minimize the amount of code that falls within an unsafe block.

* To be pedantically correct, the compiler knows full well that a raw pointer needs to point at a live allocation of the correct type, if you want to dereference it, and the compiler has similar knowledge of most of the other unsafe superpowers. But the compiler does not know about all the state surrounding that raw pointer, so (for example) it does not know that the pointer is always valid for reads when some flag is set, or any more complicated variation of that pattern. You can write a wrapper which enforces such an invariant in safe code, but the implementation of that wrapper ultimately still needs to use unsafe internally. There is no workaround for this, because the whole point of unsafe is to function as an escape hatch for things the compiler does not understand.