I'm pretty sure most big software projects (Windows, Linux, Chrome, gcc, LLVM, AAA game engines, ...) are still writing a lot of new C and C++. Pretty much everyone in the embedded world is as well.
As a solo programmer, I still prefer C and C++. In fact, as I've incorporated LLMs in to my workflow, I've been increasingly drawn toward C and its simplicity. A lot of the QoL features of C++ simply aren't needed when you're writing less code manually.
Far from it. Until Rust can read C++ code seamlessly, there will be more code written in C++ than Rust for the foreseeable future. HPC, Finance, AI, Games, Databases, Hardware all continue to be written in C++.
Strange position in 2026. If there is any writing in the wall it is this. Nobody is going to be writing Rust code from scratch given where LLMs are already now, much less in 5 years. A golden rule of software is fresh coding is a small part of the lifecycle most of it is maintenance. You may be able to get people to write Rust code (vibe code it), however a tiny minority of them will want to maintain LLM generated Rust code!! Rust will most likely be an intermediate representation - a security/formality check of sort - before converted into the appropriate heterogenous code across GPU/CPU/TPU/XPUs. Even there some other better representation will supplant it as Rust's ideas will be found too limiting. The idea that you as a programmer will sit and write Rust source code is just going to look very archaic. Thank god for LLMs for saving everyone just in time.
For game development its hard to see how Rust can really replace C++ in practice. It'll take 15 years at minimum to replace the current development ecosystem for building games
Unfortunately for me, yes. Some companies are very risk adverse and would rather stick with the devil they know. They have no idea what they are sacrificing.
Today I went over a TODO comment from 2007 in a C++ codebase that is still evolving very vividly, year after year. Trust me, for well established projects C++ is there to stay.
C++ seems alive and well in the defense space. The big contractors near me have tons of C++ job postings and I don't think I've seen a single one looking for Rust.
The new drone companies seem to favor Rust more. Helsing sponsors a lot of Rust conferences and stuff. Quantum Systems has job postings for embedded Rust. For companies that don't have a lot of legacy influencing their decisions, Rust is pretty much always going to be in their software stack. The big primes will probably come around to it in a decade or so.
This sparked an interesting memory for me. I was once working with a customer who was producing on-board software for a missile. In my analysis of the code, I pointed out that they had a number of problems with storage leaks. Imagine my surprise when the customers chief software engineer said "Of course it leaks". He went on to point out that they had calculated the amount of memory the application would leak in the total possible flight time for the missile and then doubled that number. They added this much additional memory to the hardware to "support" the leaks. Since the missile will explode when it hits its target or at the end of its flight, the ultimate in garbage collection is performed without programmer intervention.
From the job postings, many of them seem to be physics simulations of various kinds where (in my experience) memory is allocated on the heap without a second thought. Well, there are second thoughts, but those second thoughts are about performance.
Yes mine is, because they have a huge amount of C++ already and none of it is publicly accessible so security isn't a concern. (Obviously there are many other reasons to prefer Rust, but that is a big one.)
Are you just being snarky, or do you have something more specific to say about something that's choosing C?
Considering that it's been 54 years, and we've yet to find any human being, any at all[1], who can write C without UB, I'd say that writing C in 2026 when there's any other option is basically misconduct and a good case could be made that if the code touches money in any way, then it could be a SOX violation too.
Writing C today is like still writing Cobol. Yes, if you are adding a new type of savings account to your bank, and the rest is in Cobol, then sure write it in Cobol.
Some microcontroller projects may have an ecosystem in C that makes other options harder in practice, but it's still a worthy investment to not use C. There's a reason phone baseband firmwares are moving away from C.
[1] No, not even djb, who people like to bring up.
> Considering that it's been 54 years, and we've yet to find any human being, any at all[1], who can write C without UB
Undefined behavior does not mean that a language is useless. C is quite nice to write as an abstraction over assembly, and I highly recommend writing C code and thinking about (and checking) what assembly it compiles into.
Also, it is possible to verify that the types of UB that you are referring to do not occur: see the seL4 project, which provides machine-checked proofs for an OS kernel that no execution can reach a state that is undefined by the language specification.
> Undefined behavior does not mean that a language is useless.
Never said it was useless. But it's pretty damning that literally nobody can write correct code in the language. And my point is that it's been enough time that it can't be seen as a skill issue.
> C is quite nice to write as an abstraction over assembly, and I highly recommend writing C code and thinking about (and checking) what assembly it compiles into.
Absolutely. I think in order to understand programming you need to be able to write C, and be able to read assembly.
C isn't "high level assembly", with the whole discussion about the spec talking about the abstract machine, but one does not need to be a C language lawyer to be a good programmer.
But to your point about checking the output: That goes for Rust too, and godbolt.org supports Rust too, for this workflow.
So I'm not saying C is useless. But I am saying that if someone were to decide to write their greenfield project in C, then if it plans to have actual users (as opposed to a fun project), then it's basically misconduct.
Cf. Steve Gibson writes his software in assembly, still. Because he enjoys it, and his enjoyment is the primary user. I respect that. But I would NEVER hire someone to write whole applications like that in assembly. Or C.
They aren't being snarky, they're stating a fact. Rust, rounding to the nearest percent, does not exist. It's a trendy language among the Silicon Valley types that HN draws, but 99.9% of the world runs on C/++, OSes written in C/++, and language VMs implemented in C/++. Maybe some day it will change, but hanging around here too much will give you a very skewed idea of how widely adopted it is.
Well, "grownups with important jobs write C" can be taken in two ways. Non-snarky, sure. There are MANY people who write C professionally.
Not as many as there are Python, Java, JS, or C++ programmers. Depending on the survey, C seems to be neck and neck with PHP.
I read the comment the other way, though. The way that says that those other more popular languages are not serious, and NOT for grownups with important jobs.
Python, Java, and JS are all implemented in C/++. C++ is an extension of C. Taken strictly, sure, not everyone is literally writing C. But C powers everything. It is still the systems language of the world, that is the foundation of all of our systems, including both embedded and phone/PC OSes. Then there's a bit of COBOL and Fortran for mainframes, Ada for military hardware, and a whole notta Rust anywhere.
Think about what Rust software people actually use. Codex CLI, uv, ripgrep, and what else? That's three pieces of software, all development tools for development nerds. Normal people aren't engaging with any of this stuff. Your metaphorical grandma has never used software written with Rust in her life.
Cobol powers the world's money and international travel. Not sure how that matters.
> Think about what Rust software people actually use
More and more Chrome, Google, Android, Cloudflare, Prime Video, and phone basebands, parts of Linux kernel, and many other things.
Normal users literally use those all day every day.
Are they 100% Rust? Of course not (well, I don't actually know if some phone basebands are, by now. Naturally very closed source). But they're not 100% another-language either.
If C disappeared from the world, the world would stop, yes. Same with Cobol. Same with Java. Same with C++. Same with assembly.
If I were to guess (completely without basis for my guess) about the number of lines of code that normal users exercise in a normal day (counting each line just once), my bet would be on Java or JS.
Would the Java be able to run without the C code? No. But normal users would not be able to do anything if only C was left. And all banks would be gone.
And in any case C would not be able to do anything without transistors.
1% of code in some obscure module that's barely used being written in Rust does not give one claim to those things being written in Rust. Even Firefox is only 10% Rust despite the language being designed by Mozilla, and they abandoned their project to write a new browser engine in Rust.
I pointed to a jetbrains study, and then there's a stackoverflow survey[1] showing C neck and neck with PHP at 11th place among professional developers.
We all know there's lots of important C code out there. I don't see anyone going "RIIR!!!" in this thread.
But obviously yes, the 11th place language will have MANY programmers working on it. Not as many as JS by far. But many. In that survey Go is just after PHP. There are also many many Go programmers.
We are not yet at risk of running out of C programmers, like the Cobol situation. Nor do I want us to.[2]
But what point are you trying to make by so strongly defending C and the comment "grownups with important jobs write C"?
The point I am trying to make is that C is a production language and Rust is not a production language, so the original comment is pretty much correct if you take adults with jobs to mean writing software used in production. People use JS, your JS engine is written in C++, running in a browser written in C++, running on an OS written in C/++. Whatever higher-level language you use, it's powered by C/++. Your game engines are written in C/++. Your fucking car is written in C. It's not even an argument about what is better or what people should use or anything like that. It's just acknowledging reality. You're talking about how "writing new C in 2026 is misconduct" like it's a relic of a bygone era when in actuality the world around you is a world written entirely in C with, rounded to a whole percent, literally 0% of the software anyone uses being written in Rust.
Your argument was that the only Rust projects there are are little developer tools, so Rust isn't a production language. When pointed out there are large projects that every day users rely on that use Rust, and not just in corners of the codebase, code that's exercised by approximately all users, you insist it's still not production?
There's RustPython and far more compatible than IronPython back in the day. C++ is NOT an extension of C, they diverged a lot.
>Codex CLI, uv, ripgrep, and what else?
RustDesk, Servo/Firefox, tons of gtk4-rs on Gnome and extra tools, Librsvg, CosmicDE (Fedora Atomic with Cosmic can be slightly faster than vanilla Gnome Silverblue),
Ruffle, Gopher64, ArtCraft (both the vibecodec cr*p and the AI powered magical multimedia IDE doing crazy stuff which is fine).
I'm pretty sure most big software projects (Windows, Linux, Chrome, gcc, LLVM, AAA game engines, ...) are still writing a lot of new C and C++. Pretty much everyone in the embedded world is as well.
As a solo programmer, I still prefer C and C++. In fact, as I've incorporated LLMs in to my workflow, I've been increasingly drawn toward C and its simplicity. A lot of the QoL features of C++ simply aren't needed when you're writing less code manually.
Chrome should be ported to Rust long ago. on Windows, half of the UI can migrate tomorrow with ease.
Far from it. Until Rust can read C++ code seamlessly, there will be more code written in C++ than Rust for the foreseeable future. HPC, Finance, AI, Games, Databases, Hardware all continue to be written in C++.
Serious people in all of those industries are thinking about whether and how Rust is a fit for their needs.
Like, I agree that C++ will be around for a long while, but the writing is on the wall.
Strange position in 2026. If there is any writing in the wall it is this. Nobody is going to be writing Rust code from scratch given where LLMs are already now, much less in 5 years. A golden rule of software is fresh coding is a small part of the lifecycle most of it is maintenance. You may be able to get people to write Rust code (vibe code it), however a tiny minority of them will want to maintain LLM generated Rust code!! Rust will most likely be an intermediate representation - a security/formality check of sort - before converted into the appropriate heterogenous code across GPU/CPU/TPU/XPUs. Even there some other better representation will supplant it as Rust's ideas will be found too limiting. The idea that you as a programmer will sit and write Rust source code is just going to look very archaic. Thank god for LLMs for saving everyone just in time.
For game development its hard to see how Rust can really replace C++ in practice. It'll take 15 years at minimum to replace the current development ecosystem for building games
Unfortunately for me, yes. Some companies are very risk adverse and would rather stick with the devil they know. They have no idea what they are sacrificing.
Plenty of new C++ going on at my BigCorp employer.
Today I went over a TODO comment from 2007 in a C++ codebase that is still evolving very vividly, year after year. Trust me, for well established projects C++ is there to stay.
Games, anything that depends on LLVM, GCC, CUDA, SYSCL,....
Ah and Rust's compiler backend dependency on LLVM and in the future GCC as well.
C/C++ is still relevant for HPC, where you want to carefully optimize memory management.
Hate to break it to you but Rust is equally capable of doing all the same memory management optimizations.
I mean you can, but C/C++ is way more ergonomic for dealing with memory layouts.
Is it? How so?
I've been extracting a lot of verified C from theorem provers recently.
C++ seems alive and well in the defense space. The big contractors near me have tons of C++ job postings and I don't think I've seen a single one looking for Rust.
The new drone companies seem to favor Rust more. Helsing sponsors a lot of Rust conferences and stuff. Quantum Systems has job postings for embedded Rust. For companies that don't have a lot of legacy influencing their decisions, Rust is pretty much always going to be in their software stack. The big primes will probably come around to it in a decade or so.
C++ requires defensive programming, so I guess it fits that defense requires C++ programming.
Do you know if the code bases are of the kind where dynamic memory (among many other features) is disallowed?
Defense industry can work around that.
https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...Some of them, probably.
From the job postings, many of them seem to be physics simulations of various kinds where (in my experience) memory is allocated on the heap without a second thought. Well, there are second thoughts, but those second thoughts are about performance.
Cloudflare is all in on Rust, it's used everywhere by default, and C++ leftovers are being actively torn down.
Yes mine is, because they have a huge amount of C++ already and none of it is publicly accessible so security isn't a concern. (Obviously there are many other reasons to prefer Rust, but that is a big one.)
grownups with important jobs write C
Are you just being snarky, or do you have something more specific to say about something that's choosing C?
Considering that it's been 54 years, and we've yet to find any human being, any at all[1], who can write C without UB, I'd say that writing C in 2026 when there's any other option is basically misconduct and a good case could be made that if the code touches money in any way, then it could be a SOX violation too.
Writing C today is like still writing Cobol. Yes, if you are adding a new type of savings account to your bank, and the rest is in Cobol, then sure write it in Cobol.
Some microcontroller projects may have an ecosystem in C that makes other options harder in practice, but it's still a worthy investment to not use C. There's a reason phone baseband firmwares are moving away from C.
[1] No, not even djb, who people like to bring up.
> Considering that it's been 54 years, and we've yet to find any human being, any at all[1], who can write C without UB
Undefined behavior does not mean that a language is useless. C is quite nice to write as an abstraction over assembly, and I highly recommend writing C code and thinking about (and checking) what assembly it compiles into.
Also, it is possible to verify that the types of UB that you are referring to do not occur: see the seL4 project, which provides machine-checked proofs for an OS kernel that no execution can reach a state that is undefined by the language specification.
> Undefined behavior does not mean that a language is useless.
Never said it was useless. But it's pretty damning that literally nobody can write correct code in the language. And my point is that it's been enough time that it can't be seen as a skill issue.
> C is quite nice to write as an abstraction over assembly, and I highly recommend writing C code and thinking about (and checking) what assembly it compiles into.
Absolutely. I think in order to understand programming you need to be able to write C, and be able to read assembly.
C isn't "high level assembly", with the whole discussion about the spec talking about the abstract machine, but one does not need to be a C language lawyer to be a good programmer.
But to your point about checking the output: That goes for Rust too, and godbolt.org supports Rust too, for this workflow.
So I'm not saying C is useless. But I am saying that if someone were to decide to write their greenfield project in C, then if it plans to have actual users (as opposed to a fun project), then it's basically misconduct.
Cf. Steve Gibson writes his software in assembly, still. Because he enjoys it, and his enjoyment is the primary user. I respect that. But I would NEVER hire someone to write whole applications like that in assembly. Or C.
> who can write C without UB
Sel4?
NASA, They Write the Right Stuff. Essentially: go very slowly and carefully. Not at all like the typical cowboy coding in your typical software.
PDF: https://www.eng.auburn.edu/~kchang/comp6710/readings/They%20...
> Are you just being snarky,
They aren't being snarky, they're stating a fact. Rust, rounding to the nearest percent, does not exist. It's a trendy language among the Silicon Valley types that HN draws, but 99.9% of the world runs on C/++, OSes written in C/++, and language VMs implemented in C/++. Maybe some day it will change, but hanging around here too much will give you a very skewed idea of how widely adopted it is.
Well, "grownups with important jobs write C" can be taken in two ways. Non-snarky, sure. There are MANY people who write C professionally.
Not as many as there are Python, Java, JS, or C++ programmers. Depending on the survey, C seems to be neck and neck with PHP.
I read the comment the other way, though. The way that says that those other more popular languages are not serious, and NOT for grownups with important jobs.
Edit: actually, Jetbrains 2025 survey has C neck and neck with Rust: https://www.jetbrains.com/lp/devecosystem-data-playground/ . Both "below the fold" and less than 10% of Java.
Python, Java, and JS are all implemented in C/++. C++ is an extension of C. Taken strictly, sure, not everyone is literally writing C. But C powers everything. It is still the systems language of the world, that is the foundation of all of our systems, including both embedded and phone/PC OSes. Then there's a bit of COBOL and Fortran for mainframes, Ada for military hardware, and a whole notta Rust anywhere.
Think about what Rust software people actually use. Codex CLI, uv, ripgrep, and what else? That's three pieces of software, all development tools for development nerds. Normal people aren't engaging with any of this stuff. Your metaphorical grandma has never used software written with Rust in her life.
Cobol powers the world's money and international travel. Not sure how that matters.
> Think about what Rust software people actually use
More and more Chrome, Google, Android, Cloudflare, Prime Video, and phone basebands, parts of Linux kernel, and many other things.
Normal users literally use those all day every day.
Are they 100% Rust? Of course not (well, I don't actually know if some phone basebands are, by now. Naturally very closed source). But they're not 100% another-language either.
If C disappeared from the world, the world would stop, yes. Same with Cobol. Same with Java. Same with C++. Same with assembly.
If I were to guess (completely without basis for my guess) about the number of lines of code that normal users exercise in a normal day (counting each line just once), my bet would be on Java or JS.
Would the Java be able to run without the C code? No. But normal users would not be able to do anything if only C was left. And all banks would be gone.
And in any case C would not be able to do anything without transistors.
Rust is in use in more places than you may expect. Does the hypothetical grandma use Windows' kernel? Android? Firefox? Chrome?
1% of code in some obscure module that's barely used being written in Rust does not give one claim to those things being written in Rust. Even Firefox is only 10% Rust despite the language being designed by Mozilla, and they abandoned their project to write a new browser engine in Rust.
It's not "some obscure module" that is written in Rust. Just some examples I know of:
- Chrome currently uses https://github.com/googlefonts/fontations to implement its font handling, and text is the main thing on most web pages.
- Windows' DirectWriteCore for font handling is also now written in Rust.
- Firefox's whole CSS engine and GPU 2D rendering engine are written in Rust.
What is your point?
I pointed to a jetbrains study, and then there's a stackoverflow survey[1] showing C neck and neck with PHP at 11th place among professional developers.
We all know there's lots of important C code out there. I don't see anyone going "RIIR!!!" in this thread.
But obviously yes, the 11th place language will have MANY programmers working on it. Not as many as JS by far. But many. In that survey Go is just after PHP. There are also many many Go programmers.
We are not yet at risk of running out of C programmers, like the Cobol situation. Nor do I want us to.[2]
But what point are you trying to make by so strongly defending C and the comment "grownups with important jobs write C"?
[1] https://survey.stackoverflow.co/2025/technology#most-popular... [2] relevant comment: https://news.ycombinator.com/item?id=50187384
The point I am trying to make is that C is a production language and Rust is not a production language, so the original comment is pretty much correct if you take adults with jobs to mean writing software used in production. People use JS, your JS engine is written in C++, running in a browser written in C++, running on an OS written in C/++. Whatever higher-level language you use, it's powered by C/++. Your game engines are written in C/++. Your fucking car is written in C. It's not even an argument about what is better or what people should use or anything like that. It's just acknowledging reality. You're talking about how "writing new C in 2026 is misconduct" like it's a relic of a bygone era when in actuality the world around you is a world written entirely in C with, rounded to a whole percent, literally 0% of the software anyone uses being written in Rust.
> Rust is not a production language
Your argument was that the only Rust projects there are are little developer tools, so Rust isn't a production language. When pointed out there are large projects that every day users rely on that use Rust, and not just in corners of the codebase, code that's exercised by approximately all users, you insist it's still not production?
> Rust is not a production language because so much legacy code
You must not exist, because, rounded to a whole percent, literally 0% of the lives of people in the world are directly affected by you personally
In less than a year tons of Chromium features will be Rust based.
Even big bases as FFMPEG will be ported to Rust, as the porters' repos already use Rust's cc to compile ASM code.
And of course Qemu will be almost a mandatory candidate for obvious reasons.
For instance, quick and dirty SGI Irix emulator:
https://github.com/techomancer/iris
I doubt it, Rust developers compete only with crossfit and vegans in the race to be noticed.
You.. doubt that people use Firefox, Chrome, Windows, or Android? That it must be "attention" that's the reason those projects have Rust in them now?
There's RustPython and far more compatible than IronPython back in the day. C++ is NOT an extension of C, they diverged a lot.
>Codex CLI, uv, ripgrep, and what else?
RustDesk, Servo/Firefox, tons of gtk4-rs on Gnome and extra tools, Librsvg, CosmicDE (Fedora Atomic with Cosmic can be slightly faster than vanilla Gnome Silverblue), Ruffle, Gopher64, ArtCraft (both the vibecodec cr*p and the AI powered magical multimedia IDE doing crazy stuff which is fine).
Oh, and Harper to sharp your English skills:
https://github.com/automattic/harper
IronCalc looks better than LO Calc performance wise:
https://github.com/ironcalc/ironCalc
Gnome might be a Rust domain tomorrow and nobody would bat an eye. Fedora/RH/IBM can rewrite the Anaconda installer in Rust in no time.
Grownups with important jobs use at least a few different languages