LWN: Comments on "Comparing Rust to Carbon"

Should C++ be deprecated?

taladar — Fri, 17 Oct 2025 12:15:09 +0000

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?

LtWorf — Fri, 17 Oct 2025 08:43:12 +0000

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

Should C++ be deprecated?

taladar — Fri, 17 Oct 2025 08:29:26 +0000

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?

LtWorf — Thu, 16 Oct 2025 18:56:40 +0000

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?

taladar — Tue, 14 Oct 2025 10:52:26 +0000

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.

"Trying to represent this API in Rust just doesn't work. The language never lets mutable references alias each other,"

smurf — Wed, 08 Oct 2025 02:04:44 +0000

> Or you could reshape the API on the C++ side

That was my first thought too. I mean, the caller of this thing knows whether it's the same buffer or not. In-place modification in general allows for different optimizations than knowing that two regions don't alias.

IMHO the more apt comparison isn't greenfield vs. brownfield but, quite plainly, a culture where the C[++] users see the new kid on the block as an opportunity to clean up their own act i.e. their own interfaces, thus improving the C side of the codebase as well … or not.

Since the "or not" side is already served perfectly well by simply continuing to use C, for some value of "perfectly well" anyway. I kindof doubt that Carbon will get much traction. Which is for the best really (again IMHO): I'd rather see one effort to replace C++ with something sane+safe actually succeed, long-term, than three such projects, all with somewhat-conflicting goals and all fighting for developer mindset, not to mention time.

"Trying to represent this API in Rust just doesn't work. The language never lets mutable references alias each other,"

roc — Tue, 07 Oct 2025 08:53:01 +0000

Or you could reshape the API on the C++ side before you move code to Rust.

This is a pretty weak motivation for Carbon IMHO.

Should C++ be deprecated?

ras — Mon, 06 Oct 2025 11:49:50 +0000

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

"Trying to represent this API in Rust just doesn't work. The language never lets mutable references alias each other,"

daroc — Tue, 30 Sep 2025 13:12:23 +0000

Thank you for the detailed example; it's always great to discuss concrete code. See my other comment for a response about the API, but for other readers following along at home:

Unless I'm misunderstanding something, these examples use *mut [u8] at the same time as a *const [u8], which I agree won't cause any problems. The part I thought would be broken is using a &mut [u8] at the same time as a &[u8] pointing to the same memory.

Here's one of your example tests lightly modified to use references instead of pointers:
https://play.rust-lang.org/?version=stable&mode=debug...

Running it via MIRI does show that it triggers undefined behavior.

"Trying to represent this API in Rust just doesn't work. The language never lets mutable references alias each other,"

daroc — Tue, 30 Sep 2025 13:04:51 +0000

I think we all wish we could get more sleep sometimes; I hope your newborns are well.

But yes, if you use a single &mut [u8], I agree that there isn't a problem. So I do believe it should be possible to safely wrap this interface by using a type like this:

    enum Example<'a> {
        InPlace(&'a mut [u8]),
        OutOfPlace { from: &'a [u8], to: &'a [u8] },
    }

I can't speak for Carruth, obviously, but given my understanding of his talk, I think his response would be something like: "But the point is that introducing a Rust API like that involves doing extra work to reshape the API, which complicates a piece-by-piece rewrite from C++; with Carbon, a piece-by-piece rewrite can do the initial change of languages and the cleanup of the API as separate, more easily understood steps."

"Trying to represent this API in Rust just doesn't work. The language never lets mutable references alias each other,"

theodorvaryag — Mon, 29 Sep 2025 22:28:52 +0000

>you're taking input as an &[u8], but output as a &mut [u8].

Yeah this is incidental to me scaffolding a hypothetical API while very tired (I have a newborn, 4 children besides, and I didn't sleep much last night)

You can represent it as a single &mut [u8] and fan-out the aliased pointers behind the "safe" API. You can do more or less whatever you need/want to do and put a safe wrapper around it, I was just hewing too closely to the C FFI rough sketch in the safe API wrapper.

"Trying to represent this API in Rust just doesn't work. The language never lets mutable references alias each other,"

theodorvaryag — Mon, 29 Sep 2025 22:28:42 +0000

>Those references can't alias, so there's no way to actually call the wrapper in a way that would update the input buffer in-place, I think.

>And even if you could, the compiler might break things while optimizing because you changed the data under a &[u8], which isn't permitted.

https://github.com/bitemyapp/mut-ref-ptr-alias

You can `git clone` this repository and run the tests under Miri with `make test`. When I tested an incorrect version (calling as_mut_ptr multiple times) _that_ failed Miri. Calling `as_mut_ptr` and then deriving the aliased pointers from the original `as_mut_ptr` is not UB. Even with the unsafe code Rust can help you manage exclusive use/derivation of the original mutable pointer from the mutable reference if you like.

The optimizer won't break anything because it understands pointers can be aliased. These test cases all pass Miri. I work on a VM/interpreter that uses unsafe, raw pointers, and the like in Rust extensively: https://github.com/zorp-corp/nockchain/tree/master/crates...

If there's something these examples don't cover or you think Miri is wrong about this not being UB, please tell me so I can add more test cases or file a bug with Miri.

"Trying to represent this API in Rust just doesn't work. The language never lets mutable references alias each other,"

daroc — Mon, 29 Sep 2025 16:29:44 +0000

I'm sure there is a way to represent something like this in Rust, but I don't think your proposed solution is quite it. In the wrapper function, you're taking input as an &[u8], but output as a &mut [u8]. Those references can't alias, so there's no way to actually call the wrapper in a way that would update the input buffer in-place, I think. And even if you could, the compiler might break things while optimizing because you changed the data under a &[u8], which isn't permitted.

If I were trying to encapsulate this interface in safe Rust, I might use an enum type that contains either a normal reference or a mutable reference, and checks things at run time that way. But I'd need to think about the API design a bit more to be confident in that approach.

"Trying to represent this API in Rust just doesn't work. The language never lets mutable references alias each other,"

theodorvaryag — Mon, 29 Sep 2025 16:08:21 +0000

It's possible I misunderstood something in the article but you can do this in Rust. Rust doesn't allow mutable references to overlap/alias (this is UB), but that's precisely what mutable *pointers* in Rust are for. Miri can catch it immediately if aliasing leaks into your mutable references.

/// Low-level FFI mirror of the C++ declaration.
/// `out` and `input` may alias; every other pointer must be disjoint.
#[repr(C)]
pub extern "C" fn EVP_AEAD_CTX_seal_scatter(
ctx: *const EVP_AEAD_CTX,
out: *mut c_uchar,
out_len: usize,
out_tag: *mut c_uchar,
out_tag_len: *mut usize,
nonce: *const c_uchar,
nonce_len: usize,
input: *const c_uchar,
input_len: usize,
extra_input: *const c_uchar,
extra_input_len: usize,
ad: *const c_uchar,
ad_len: usize,
) -> c_int

/// ***Public*** helper that hides the pointer casting boiler-plate.
///
/// # Safety
/// - `out` and `input` may point to the same memory region
/// (in-place encryption) or to two completely non-overlapping regions.
/// - Every other slice must be non-overlapping with each other and with
/// the `out`/`input` region(s).
/// - All pointer lifetimes must be valid for the duration of the call.
#[inline]
pub unsafe fn encrypt_in_place_or_copy(
ctx: &EVP_AEAD_CTX,
out: &mut [u8],
out_tag: &mut [u8],
out_tag_len: &mut usize,
nonce: &[u8],
input: &[u8],
extra_input: &[u8],
ad: &[u8],
)

Different scenario, but `split_at_mut` is an example of creating a safe interface for disjoint slices of a larger vector. I don't know why you'd sacrifice safety across the other 99% of your code for an unsafe edge case that can be contained with a safe wrapper. I write a lot of unsafe Rust for a living, it's quite a bit easier to use correctly than C or C++ in part because of the ways in which you can delimit and contain it. Miri also helps.

Cf.
- https://doc.rust-lang.org/std/primitive.pointer.html#meth...
- https://doc.rust-lang.org/std/primitive.slice.html#method...

"Microservice" architecture is good alternative

mort — Mon, 29 Sep 2025 08:23:50 +0000

I have some projects with a WebRTC video call component. The way I've found to work with that is to use C++ for a "helper" video call process which uses Google's WebRTC library, and then the rest of the system (be it written in Rust, or Go, or maybe even that too is C++) communicates with the WebRTC helper process via IPC (typically line delimited JSON via stdin/stdout, maybe shared memory or DMA buffers for decoded video frames).

But because WebRTC is complicated, this C++ helper process still ends up being quite large. It would've been nice if that code too could've been written in something nicer. Carbon is interesting for that.

And then of course we all call into C libraries all the time, either directly or indirectly through a wrapper.

Hard truth

mort — Mon, 29 Sep 2025 08:18:36 +0000

I don't know what "C++ people" you're talking about, but as someone who hangs around in C++ circles a bit, my impression is that a lot of people are pretty fed up with the committee and their magical thinking around profiles. The committee and C++ users are not the same group of people.

"Microservice" architecture is good alternative

simlo — Thu, 25 Sep 2025 21:04:46 +0000

You don't do calls into another language, but build your system in several processes, each process can be written in a language of choice. Using protobuf or similar should help in avoiding implementing parts of the communication in all languages, but parts of the overall state of the system must be replicated into the various language, so the cost of adding a new language to such a system won't be zero.

Large monolith programs are in itself a bad idea - especially in memory unsafe languages. So splitting all that C++ code i to smaller programs might be a sane approach, and then add new ones in Rust - or Python or ...

Should C++ be deprecated?

farnz — Tue, 23 Sep 2025 15:53:15 +0000

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?

marcH — Tue, 23 Sep 2025 15:16:37 +0000

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?

farnz — Tue, 23 Sep 2025 08:18:27 +0000

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?

taladar — Tue, 23 Sep 2025 08:11:29 +0000

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.

Leaky Interoperability

marcH — Mon, 22 Sep 2025 23:19:34 +0000

> It's fine, in theory, to say that we should just enforce better standards. In practice people have lots to do and little time available. Perhaps Carbon will find ways to discourage temptation to write "just a little C++ to make this work"?

Yes, it's all about enforcement. One of the "easiest" ways is to tie bonuses to the "little C++" percentage. You can also block releases until that percentage falls under some target thresholds - exactly like any other quality metric. You can also inflict more mandatory review, test coverage, process overhead and what not on that percentage - making life with the "little C++" miserable.

There are plenty of ways - use your imagination. But they all require a strong, top-down push from management. That push exists in some technical enough companies. That safety push could be enough to make Carbon successful - exactly like it's been making Rust successful.

Who employs the speaker BTW? :-)

Should C++ be deprecated?

marcH — Mon, 22 Sep 2025 23:05:42 +0000

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

marcH — Mon, 22 Sep 2025 22:09:07 +0000

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

Forcing reduced size dependency trees

farnz — Fri, 19 Sep 2025 12:25:47 +0000

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.

Large libraries versus small ones

smurf — Fri, 19 Sep 2025 11:17:36 +0000

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

excors — Fri, 19 Sep 2025 11:02:27 +0000

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

Large libraries versus small ones

farnz — Fri, 19 Sep 2025 10:42:35 +0000

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.

Should C++ be deprecated?

NYKevin — Fri, 19 Sep 2025 03:52:56 +0000

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

mathstuf — Fri, 19 Sep 2025 00:51:55 +0000

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

Leaky Interoperability

ejr — Thu, 18 Sep 2025 18:38:34 +0000

And then came the battle over template instantiation methods and the ODR...

Should C++ be deprecated?

farnz — Thu, 18 Sep 2025 16:18:22 +0000

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?

pizza — Thu, 18 Sep 2025 15:46:37 +0000

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

farnz — Thu, 18 Sep 2025 15:11:50 +0000

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.

Leaky Interoperability

smurf — Thu, 18 Sep 2025 14:56:01 +0000

Well, once upon a time there was this thing called "cfront" which transcoded C++ to C …

Should C++ be deprecated?

smurf — Thu, 18 Sep 2025 14:55:51 +0000

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?

LtWorf — Thu, 18 Sep 2025 14:10:28 +0000

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?

LtWorf — Thu, 18 Sep 2025 13:55:06 +0000

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?

LtWorf — Thu, 18 Sep 2025 13:52:56 +0000

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.

Leaky Interoperability

taladar — Thu, 18 Sep 2025 07:16:25 +0000

Personally I think the "C++ is the successor of C" was only ever marketing and nobody really treated it that way in practice, so in essence it is just failed marketing.