> The bugs will only disappear until the model that was used to security test the generated code becomes obsoleted.
I think you're ignoring the distinct possibility that even if the code is not formally verified, LLMs could simply stop writing bugs, or this kind of bugs. No matter how smart an attacker AI, it cannot exploit bugs that are simply not there.
But hell, even formally verified ones can only verify back to the spec. There are plenty of examples of bugs in formally verified software.
I place a higher likelihood on LLMs winning (producing fewer bugs than formally verified) over the long run. Mostly because verified software can, IIUC, only verify back to the spec. Whereas LLMs can go "uh, your spec itself has a bug, you really want me to codify that?".
Luckily we have newer models going back and fixing these things.
In terms of the set of all bugs, the AIs from 2022-2023 pale in comparison with the amount of bugs written by hand in previous half century, even if 2022 AIs were worse than the average programmer.
That study is from 2022, with at most a last update 2023? (if I read it right)
I'm not at all saying that "oh 3 weeks ago, discard", but three years ago absolutely has a "before and after".
Three years ago AI generated code could basically not be used at all, and I had to rewrite just about every line. Today I have to watch out for generated code making steps in the wrong strategic and architectural direction, and over engineering, no longer hallucinating nonexisting APIs and forgetting to check the auth token.
I still look for those kinds of mistakes, but I think citing a 2022 paper for "can AI do X" is not useful.
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.
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.
C without UB is basically impossible, but C that does the right thing based on assumptions about the platform is possible. I'm not against Rust taking over, just can see C holding out quite long because it's really not that bad.
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.
You have a point but it's just hyperbole in the other direction. Yes, Rust is only a small fraction of the code in use every day, but it has nonetheless achieved deep penetration into critical infrastructure.
Cloudflare's network routing code is predominantly Rust. Massive parts of AWS and Azure are Rust (including crown jewels like S3 and Lambda). Multiple car manufacturers have shipping Rust code in their production cars for years, albeit yes it's a slow process intoroducing it into regulated industries. Airbus and Boeing are putting up job openings for Rust development. As mentioned critical pieces of Windows and Android are now written in Rust. If you use Discord - that's Rust. If you use Amazon Prime Video or Disney+, that's Rust. I could go on.
When like 40% of internet traffic and 75% of end user devices are using Rust in some capacity, to say that it's "not production" is just ignorant, arrogant nonsense.
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?
Most things in the world are not made of zinc. But to therefore say that we live in a world without zinc in production is not a correct conclusion (https://youtu.be/jWpPrWHBHcQ).
> running in a browser written in C++
As other have pointed out, that browser would not render fonts without Rust. You use your browser without fonts? I mean, it's not impossible. Some people navigate the web using screen readers.
> running on an OS written in C/++
Except the parts that are written in Rust or other languages, sure.
So tautologically, the parts that are not written in other languages, are written in C and C++. That's technically correct, the best kind of correct.
> Whatever higher-level language you use, it's powered by C/++
"Powered by" in that it runs on an OS written in C, assembly, and C++, sure. Still not relevant. Languages tend to want to "self-host".
> Your game engines are written in C/++
Well, most gaming hours in the world are probably spent on games written in C#, Java, Kotlin, Swift, and Objective-C. And JS.
JetBrains 2025 study has 40% of game development as C#. C++ just 29%.
AAA games, sure. But it's understatement of the year to say that because AAA games are written in C++ that means it's the only production language.
> Your fucking car is written in C
I think you're stuck in the past. This is no longer a categorically true statement.
The world changes. It used to be a true statement that "americans don't even have passports". In 1989 only 3% had passports, and the world could mock that figure. Today it's 48% and rising.
Just like you should no longer say "americans don't even have passports", because while the percentage may not be a record, it's no longer true, you should stop saying other things when they are no longer true.
> literally 0% of the software anyone uses being written in Rust.
As I have others have repeatedly proved to you, this is literally (actual literally, not as a rhetorical device) false.
I guess you could live in a world with 0% Rust. Your car is old, your Linux kernel was compiled to exclude Rust parts (not sure this is possible. Haven't checked), and you don't run anything Chromium-based, or Firefox. And you don't own an Android phone.
But you saying (asserting without evidence) that it's only minor systems in these omnipresent systems that use Rust, then… uh… what's your point? In a car, if C controls fuel injection and Rust controls the power steering, does that "not count", and you'd still claim "literally 0%"?
But… like, if you have an iPhone instead, do you think it doesn't run anything Objective-C or Swift?
I think it's accurate enough to say that "Cloudflare runs on Rust".
You think you, and normal people, never use Cloudflare? Cloudflare hosts like a a quarter of web traffic.
A quarter of web traffic runs on Rust. In production. Right now.
> You're talking about how "writing new C in 2026 is misconduct" like it's a relic of a bygone era
Just like with Cobol, in an existing system it does have its place for extending existing code.
But that "new" is key.
> world around you is a world written entirely in C
Entirely? No. Nobody's saying there's no C code in existence. I don't know why you care to defend against that imagined claim.
> rounded to a whole percent, literally 0% of the software anyone uses being written in Rust.
Does it matter, if (say for example) your pacemaker or car ignition runs Rust?
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 can deal with large builds, what I cant deal with is time. My rust web application takes 20 minutes to build in release mode on a high end developer machine. I can’t build it in ci/cd.
20 minut definitely sounds suspicious. For comparison, Rust compiler takes ~10 minutes to build in release mode (in the simple config without all the fancy PGO stuff we run on CI).
Do you have some more info about the codebase, is it public?
There's nothing public, but it's a SaaS application written with actix-web, askama and sqlx.
One of the big slow downs comes from a single crate (async-stripe). In retrospect, I should just use reqwest and serde to do everything with Stripe's API manually and not use any crate at all (especially if it cuts the build time in half).
I see, thanks. I assume `async-stripe` is auto-generated from some IDL, those crates sometimes bump into some pathologial pattern, I'll check it out.
`actix-web` itself should be fine, `sqlx` can be heavy if you use its compile time features, I'd assume `askama` is heavy as well, just based on the description (it generates rust code at compile time).
Otherwise it depends on how the code is structured (e.g. how generic it is, how deep types or complicated futures it creates).
Yeah, there are some things I've done to mitigate this, especially for the dev loop. Moving templates out of rust (losing some safety). Splitting the application into vertical slices. Only generating code that's changed. Turning features into crates.
I am not the parent commenter, but I have the same sense that the GNU ones are better.
But the only concrete example I can think of is that `cat -n a b`, if `a` doesn't end in a newline, produces something that is obviously not what the user wanted. GNU cat does it right.
I didn't report it to the openbsd people because I didn't want them to yell at me that `-n` is nonstandard anyway with no "right" behavior, so I should STFU. Which would be what I'd expect from having reported problems in the past.
I think the behavior in the GNU clone is more consistent with "we added line numbers to the concatenation tool" while whoever added it to OpenBSD's ancestry was probably more concerned with generating listings for printing.
Personally, I'd remove even the POSIX [-u] flag from all cat versions because all of them are un-UNIX-like.
Some GNU tools are particularly ridiculous with the Easter egg features I only know about because LLMs use them all the time —and I have been using Linux for 30 years.
Because you don't like the design(I don't either) but it carries information.
Someone could have thought it was a good idea and no one was willing to audit all of UCB's scripts to fix the "bug" even if it had been the result of a lazy implementation because ed(1) on a terminal.
My choice of wording is from my assumption that nobody, at any point, actually wanted that behaviour. And I stand by that being a pretty safe bet.
So I wouldn't refer to it as "the design". It's not that the methods are unsound, it's that I don't see any method at all.
As for not wanting to break existing scripts, OpenBSD is not even remotely as concerned about backwards compatibility as Linux is. I don't mean that in a derogatory way. It's a perfectly cromulent choice.
Not that remarkable. Nobody in history has been able to write correct C code, and that includes OpenBSD developers.
I pointed an AI at the smallest two tools in OpenBSD I could think of, cat and find, and found multiple bugs. One of which was a buffer overflow (albeit unlikely to be exploitable). IIRC these bugs had existed since at least the NetBSD/OpenBSD split.
I looked for bugs in Linux coreutils on a Russian Elbrus PC.
It has a very interesting protected mode of operation where every memory pointer is tagged.
So, I just ran tests and quickly found a number of memory-related bugs.
I’ve submitted some patches, but they were never accepted. These tools’ maintainers seemed very inertial to me. So maybe this is why many (low importance, I assume) issues persists there for a long time.
I feel like this is the elephant in the room. People keep acting surprised these large codebases are full of bugs and exploits. C isn't a safe language and moving to safe languages is going to be the only lasting solution.
No language is safe, but I assume you mean memory safety in particular. Alternatives are to formally verify the C code to be memory safe or to add some memory safety features to C. Both certainly simpler and cheaper than rewriting everything.
Whether memory safety is really that important is also not clear. Most people get hacked because they run old software or insecure configurations. So a language such as Rust which creates more supply chain risks seems problematic.
It has needed some fixing over the years. errno was one thing. There have been a number of things in that vein, where Bernstein relied upon 1989 C or even K&R semantics and suchlike.
But compared to some other code from the 1990s, it has lasted the test of time quite well.
I think you're ignoring the distinct possibility that even if the code is not formally verified, LLMs could simply stop writing bugs, or this kind of bugs. No matter how smart an attacker AI, it cannot exploit bugs that are simply not there.
But hell, even formally verified ones can only verify back to the spec. There are plenty of examples of bugs in formally verified software.
I place a higher likelihood on LLMs winning (producing fewer bugs than formally verified) over the long run. Mostly because verified software can, IIUC, only verify back to the spec. Whereas LLMs can go "uh, your spec itself has a bug, you really want me to codify that?".
reply