4 ms·

C and C++ are kind of losing out to Rust right now. Take ladybird (last month blog; not that ladybird stands for all projects out there, of course; it is just

C and C++ are kind of losing out to Rust right now. Take ladybird (last month blog; not that ladybird stands for all projects out there, of course; it is just an example): https://ladybird.org/newsletter/2026-05-31/ https://ladybird.org/newsletter/2026-05-31/ "The HTML parser is now written in Rust" "The Rust parser is also about 10% faster than the C++ version it replaced," I am not saying this is a systematic analysis by far, but Rust is pushing into domains where C and C++ dominated in the past. And that seems to be a real push. To me it looks as if both C and C++ are standing to lose some ground in the next few years, directly to Rust. Perhaps even via snowball effect.

deleted 4mo ago
[deleted]
ghosty141 4mo ago
> but Rust is pushing into domains where C and C++ dominated in the past. I think it's also a big sign that the linux kernel adopted rust and not c++. (only for small parts but still)
- tialaramex 4mo ago
  A not inconsiderable part of why is that Rust for Linux did the work. When C++ people say they think there should be C++ in Linux, their proposal usually begins by proposing that it "should" be possible to just compile Linux as C++ software. This doesn't work because C isn't just "C++ but old", and they rapidly lose interest. Which of course also feeds into Linus' semi-fair claim that not allowing C++ keeps out the low effort wannabes who would plague such a project. This makes C++ developers very angry, but part of the reason why is that it's true, C++ does attract these people. The Rust for Linux people wrote a lot of code, a lot of documentation, they did Q&As, they worked very hard to actually deliver the idea to the kernel community, it's a totally different approach, it's a lot more work but some people thought it was worth the work.
  - cesarb 4mo ago
    > their proposal usually begins by proposing that it "should" be possible to just compile Linux as C++ software That has already been done in the past. Quoting the FAQ: "[...] the kernel was once modified to be compiled under g++. That lasted for a few revisions. People complained about the performance drop. It turned out that compiling a piece of C code with g++ would give you worse code. It shouldn't have made a difference, but it did. Been there, done that."
    - pjmlp 4mo ago
      Yet the C compilers they use are written in C++. It was mostly a Linus issue, and not wanting to fix what were the root causes of the regressions.
  - saghm 4mo ago
    Honestly this just makes it sound like C++ people either didn't really care about it in practice or just were weirdly insistent that they get to decide how to integrate the language into an existing project. At best, it's just another instance of the claims that C++ could totally do everything Rust does (but somehow still never seems to in real life), and at worst it just kind of reflects poorly on the social skills of the people who tried to push it.
    - pjmlp 4mo ago
      Too busy contributing to Symbian, Windows, macOS, BeOS...
      - saghm 4mo ago
        Sure, not caring about contributing to Linux in practice is valid, but at that point it would make more sense just not to argue about the aptness of C++ for integrating into Linux at all then if no one ever legitimately tried. My point is that the parent comment is trying to have it both ways by arguing that C++ totally could be integrated into the Linux kernel as a dismissal of the real-world case of Rust being integrated but then ignoring the actual real-world case of C++ not getting integrated into the kernel. At a higher level, I've noticed a long-term trend where dismissals of Rust from C++ proponents have continued to grow increasingly abstract; the line of reasoning basically seems to be that how Rust is used in practice can be ignored as long as there's a sufficient theoretical argument for C++ being able to do the same thing. This is a remarkable retreat from the previous objections to Rust being impractical compared to C++ which I'd argue is itself evidence of the ground that Rust has gained in the past several years. It seems to have happened without the C++ community noticing though, which at least in part seems to come from some cognitive dissonance; in your two replies to my comments in this thread, you demonstrated this yourself by arguing on pragmatic grounds about how C++ is used in practice in this comment but then rejecting criticism of C++ in your other comment by asserting that a "recipe" for memory safety is enough to dismiss concerns about how pretty much no real-world project actually achieves this. My (obviously biased) perception is that the shortcomings of Rust tend to be pretty widely agreed upon by the experts in the community and mostly dismissed by people who honestly aren't nearly as experienced in the language, whereas with C++ the most expert members of the community seem prone to handwaving away concerns that deserve a lot more attention.
- pjmlp 4mo ago
  Because Linus, plenty of other OSes have adopted C++ on their internals.
360MustangScope 4mo ago
I agree about Rust gaining ground but using the argument that it got 10% faster due to Rust is not really that useful. If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal.
- cogman10 4mo ago
  I think the difference in languages that allows for faster performance is that Rust does a good job of surfacing expensive operations and it makes defensive programming less of a requirement.
- tialaramex 4mo ago
  > If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal. This speculation has been offered every time. It's not crazy to think this might be true, but it's also not crazy to think that if C++ keeps leaving performance on the table and Rust doesn't that adds up for real projects. When Titus wrote "ABI: Now or Never" in 2020 he estimated 5-10% aggregate loss. Things that you could fix, if you started over, but C++ refuses to do that because of ABI and so it doesn't have these fixes, whereas in most cases† Rust does. So I can well believe that a blow-for-blow port could get you 10% perf win. † One of the examples Titus cites is the "Small String Optimization". Rust deliberately doesn't do SSO for its standard library collection String, but several really nice SSO optimised types are available, including ColdString and CompactString, which are way better than what's provided in C++ if that's what you need.
  - tick_tock_tick 4mo ago
    Until Rust has equal meta-programming support to C++ it's always going to be "slower". That's why people always say this because it's always true there is nothing Rust can do C++ can't but there is quite a few things you can do in C++ but not in Rust. Realistically the difference doesn't matter much and if you're writing code that must be as fast as possible your writing unsafe Rust that looks a lot more like C/C++ then anything Rust.
reallyinchaos 4mo ago
[dead]
- vouwfietsman 4mo ago
  Knowing little about cpp modules and nothing about Gabriel Dos Reis, I expect a more design-by-committee type explanation for the result: the module system was probably a victim of having to be backwards compatible, abi stable, idiomatic, zero cost abstraction, be compatible with all weird cpp features, not hurt compile time, etc etc etc I don't think its fair to attribute it to lack of skills or bad intent, unless there's some proof to any of it.
  - reallyinchaos 4mo ago
    [flagged]
- jooops1 4mo ago
  Yep I agree C++ lacks many features Rust has solid support for. But the real issue with C++ is the development process, almost all the people involved in the Module system are rather old and worked for Microsoft once. They are just in their own bubble and not having an open RFC-process blocks experts in that field.
FpUser 4mo ago
>"are kind of losing out to Rust right now" On publicity side / propaganda / some specific areas you might have a point. Practically amount of C++ code being in active development (I wat to stress this particular point) dwarfs that of Rust despite all that high profile pressure. Personally I consider languages as just a tool and do not get hung up when client prefers this or that and I have developed all kinds of software in many languages. If asked for my own opinion - for general development I consider Rust very restrictive and poor expression-wise comparatively to C++, I think it is a case when developer become servant of a tool. P.S. last sentence edited
pjmlp 4mo ago
> C and C++ are kind of losing out to Rust right now. Depends on the domain, there are enough fields where Rust still doesn't have an answer for. Example, the compilers it depends on (botstraping on Cranelift when?), Khronos and POSIX industry standards, HFT, HPC, console devkits, AI frameworks, VFX reference platform,.... It will get there, eventually, maybe.

deleted 4mo ago

[deleted]

ghosty141 4mo ago

> but Rust is pushing into domains where C and C++ dominated in the past. I think it's also a big sign that the linux kernel adopted rust and not c++. (only for small parts but still)

tialaramex 4mo ago
A not inconsiderable part of why is that Rust for Linux did the work. When C++ people say they think there should be C++ in Linux, their proposal usually begins by proposing that it "should" be possible to just compile Linux as C++ software. This doesn't work because C isn't just "C++ but old", and they rapidly lose interest. Which of course also feeds into Linus' semi-fair claim that not allowing C++ keeps out the low effort wannabes who would plague such a project. This makes C++ developers very angry, but part of the reason why is that it's true, C++ does attract these people. The Rust for Linux people wrote a lot of code, a lot of documentation, they did Q&As, they worked very hard to actually deliver the idea to the kernel community, it's a totally different approach, it's a lot more work but some people thought it was worth the work.
- cesarb 4mo ago
  > their proposal usually begins by proposing that it "should" be possible to just compile Linux as C++ software That has already been done in the past. Quoting the FAQ: "[...] the kernel was once modified to be compiled under g++. That lasted for a few revisions. People complained about the performance drop. It turned out that compiling a piece of C code with g++ would give you worse code. It shouldn't have made a difference, but it did. Been there, done that."
  - pjmlp 4mo ago
    Yet the C compilers they use are written in C++. It was mostly a Linus issue, and not wanting to fix what were the root causes of the regressions.
- saghm 4mo ago
  Honestly this just makes it sound like C++ people either didn't really care about it in practice or just were weirdly insistent that they get to decide how to integrate the language into an existing project. At best, it's just another instance of the claims that C++ could totally do everything Rust does (but somehow still never seems to in real life), and at worst it just kind of reflects poorly on the social skills of the people who tried to push it.
  - pjmlp 4mo ago
    Too busy contributing to Symbian, Windows, macOS, BeOS...
    - saghm 4mo ago
      Sure, not caring about contributing to Linux in practice is valid, but at that point it would make more sense just not to argue about the aptness of C++ for integrating into Linux at all then if no one ever legitimately tried. My point is that the parent comment is trying to have it both ways by arguing that C++ totally could be integrated into the Linux kernel as a dismissal of the real-world case of Rust being integrated but then ignoring the actual real-world case of C++ not getting integrated into the kernel. At a higher level, I've noticed a long-term trend where dismissals of Rust from C++ proponents have continued to grow increasingly abstract; the line of reasoning basically seems to be that how Rust is used in practice can be ignored as long as there's a sufficient theoretical argument for C++ being able to do the same thing. This is a remarkable retreat from the previous objections to Rust being impractical compared to C++ which I'd argue is itself evidence of the ground that Rust has gained in the past several years. It seems to have happened without the C++ community noticing though, which at least in part seems to come from some cognitive dissonance; in your two replies to my comments in this thread, you demonstrated this yourself by arguing on pragmatic grounds about how C++ is used in practice in this comment but then rejecting criticism of C++ in your other comment by asserting that a "recipe" for memory safety is enough to dismiss concerns about how pretty much no real-world project actually achieves this. My (obviously biased) perception is that the shortcomings of Rust tend to be pretty widely agreed upon by the experts in the community and mostly dismissed by people who honestly aren't nearly as experienced in the language, whereas with C++ the most expert members of the community seem prone to handwaving away concerns that deserve a lot more attention.
pjmlp 4mo ago
Because Linus, plenty of other OSes have adopted C++ on their internals.

360MustangScope 4mo ago

I agree about Rust gaining ground but using the argument that it got 10% faster due to Rust is not really that useful. If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal.

cogman10 4mo ago
I think the difference in languages that allows for faster performance is that Rust does a good job of surfacing expensive operations and it makes defensive programming less of a requirement.
tialaramex 4mo ago
> If they rewrote it in C++ again, they would have most likely got the same result because they got a chance to fix a design that might not have been most optimal. This speculation has been offered every time. It's not crazy to think this might be true, but it's also not crazy to think that if C++ keeps leaving performance on the table and Rust doesn't that adds up for real projects. When Titus wrote "ABI: Now or Never" in 2020 he estimated 5-10% aggregate loss. Things that you could fix, if you started over, but C++ refuses to do that because of ABI and so it doesn't have these fixes, whereas in most cases† Rust does. So I can well believe that a blow-for-blow port could get you 10% perf win. † One of the examples Titus cites is the "Small String Optimization". Rust deliberately doesn't do SSO for its standard library collection String, but several really nice SSO optimised types are available, including ColdString and CompactString, which are way better than what's provided in C++ if that's what you need.
- tick_tock_tick 4mo ago
  Until Rust has equal meta-programming support to C++ it's always going to be "slower". That's why people always say this because it's always true there is nothing Rust can do C++ can't but there is quite a few things you can do in C++ but not in Rust. Realistically the difference doesn't matter much and if you're writing code that must be as fast as possible your writing unsafe Rust that looks a lot more like C/C++ then anything Rust.

reallyinchaos 4mo ago

[dead]

vouwfietsman 4mo ago
Knowing little about cpp modules and nothing about Gabriel Dos Reis, I expect a more design-by-committee type explanation for the result: the module system was probably a victim of having to be backwards compatible, abi stable, idiomatic, zero cost abstraction, be compatible with all weird cpp features, not hurt compile time, etc etc etc I don't think its fair to attribute it to lack of skills or bad intent, unless there's some proof to any of it.
- reallyinchaos 4mo ago
  [flagged]
jooops1 4mo ago
Yep I agree C++ lacks many features Rust has solid support for. But the real issue with C++ is the development process, almost all the people involved in the Module system are rather old and worked for Microsoft once. They are just in their own bubble and not having an open RFC-process blocks experts in that field.

FpUser 4mo ago

>"are kind of losing out to Rust right now" On publicity side / propaganda / some specific areas you might have a point. Practically amount of C++ code being in active development (I wat to stress this particular point) dwarfs that of Rust despite all that high profile pressure. Personally I consider languages as just a tool and do not get hung up when client prefers this or that and I have developed all kinds of software in many languages. If asked for my own opinion - for general development I consider Rust very restrictive and poor expression-wise comparatively to C++, I think it is a case when developer become servant of a tool. P.S. last sentence edited

pjmlp 4mo ago

> C and C++ are kind of losing out to Rust right now. Depends on the domain, there are enough fields where Rust still doesn't have an answer for. Example, the compilers it depends on (botstraping on Cranelift when?), Khronos and POSIX industry standards, HFT, HPC, console devkits, AI frameworks, VFX reference platform,.... It will get there, eventually, maybe.