I think this is the breaking point where replacing our code written in C for code written in memory safe languages is becoming urgent.
The vast majority of vulnerabilities found recently are directly related to being written in memory unsafe languages, it's very difficult to justify that a DNS/DHCP server can't be written in rust or go and without using unsafe (well, maybe a few unsafe calls are still needed, but these will be a very small amount)...
They really are, though. Security is all-encompassing, including not just programming languages, libraries, programs, but also systems, humans and their processes. Don't forget physical security either.
There are no silver bullets, and if the Rust Hype Squad told you there were and all you had to do was buy their product, they were just bamboozling you to push adoption of their pet language.
Write in whichever language you like. Including Rust. Including C. Even PHP. You can write secure software if you put your mind to it.
That's not a great analogy. There are no pick-proof locks (...that are mechanically operated and admit keys; I'm presuming you didn't mean "pick-proof" in that there is no keyhole to pick but is defeated some other way, e.g. a keypad, you meant maximally pick-resistant in contrast to "easily picked")
And honestly? No! If someone can kick your door down, don't waste your money on a super-secure lock, they will just kick your door down. And if you're having your door kicked down on the regular, don't even focus on bolstering the door (they'll either start using power tools or take some other tact like smashing your windows or drilling through the floor or roof). Leave the door open if you like, but move whatever's attracting the attention of intruders somewhere more defensible. Focusing on the securing the wrong thing is also a security flaw!
Ah...these security issues are perfectly cromulent because my shiny new magical beans language let's me screw up in brand new ways, not the old and busted boomer screwups. New is always awesome.
How many CVEs in coreutils over the years? The project has the advantage of being old enough for them to be fixed. Call me when the rust rewrite has been there that long and still has more CVEs than the GNU counterpart.
Maybe coreutils is so old that most security vulnerabilities was solved before CVE even existed. But I think this is also a good argument why we are replacing a solid piece of C code to Rust just because it is "memory safe" and then have lots of CVEs related to things like TOCTOUs (that Rust will not save you).
I'm not against rewriting it in Rust because I believe it really may help in certain class of bugs, but indeed it should not be replacing the old version instantly for that reason. Both could co exist, even tho you still need some guinea pigs to test it out and find issues.
Other than security, Rust brings major improvement to the tooling and may help bring fresh members that wouldn't want to contribute to C code. I understand why some projects go that route
> Other than security, Rust brings major improvement to the tooling and may help bring fresh members that wouldn't want to contribute to C code. I understand why some projects go that route
But it loses old members who don't program in rust, already know the projects, all the reasons of why "this thing" was done "that way". and introduces a new set of bugs, plus now you have two versions of the same thing to maintain.
People thinking that using a superior tool (on paper) enables them to automatically write better tools than the ones who are battle tested over the years baffles me to no end.
Yes, you can go further, possibly faster. OTOH, nothing replaces experience and in-depth knowledge. GNU Coreutils embodies that knowledge and experience. uutils has none, and just tries to distill it with tests against the GNU one.
...and they get 44 CVEs as a result in their first test.
There was an article posted to HN recently that enumerated bugs in the rust rewrite.
Iirc the bugs had to do with linux system details like fs toctou and other things you'd only find out about in production.
Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs, so that every project doesn't have to relearn them at runtime. But the rewrite isn't pure downside.
I'm personally not against Rust rewrites in principle. But doing them in this drive-by hostile manner, esp. with non-GNU licenses smells "hostile takeover" for me, and dismantling core free software utilities is not nice in general.
> Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs
I believe trying to make something idiot-proof just generates better idiots, so I prefer having thinner abstractions on the lower level for maintenance, simplicity and performance reasons. The real solution is better documentation, but who values good documentation?
Graybeards and their apprentices, mostly from my experience. I personally still live with reference docs rather than AI prompts, and it serves me well.
My read on those was basically that the classic filesystems are hopelessly broken and we need ACID guarantees in the next-gen filesystems, like 20 years ago.
Not saying all of them were about FS TOCTOU bugs but once I got to these, that was my takeaway.
Obviously just using Rust cannot fix _all_ bugs, and I reject any criticisms towards Rust rewrites that tear down this particular straw man (its goal being to make it impossible to argue against). That's toxic and I get surprised every time people on HN try to argue in that childish way.
But if we can remove all C memory safety foot guns then that by itself is worth a lot already.
Losing decades-old knowledge on how the dysfunctional lower-level systems work would be regrettable and even near-fatal for any such projects. That I'd agree with. But it also raises the question on whether those lower-level systems don't need a very hard long look and -- eventually -- a replacement.
I like rust as a language, but boy, the violent, zero-sum proselytising gets on my nerves. It's not enough for Rust to win, but C must be beaten to a pulp and its head mounted on a pike.
New projects wearing an another project's skin have always bothered me - regardless of language. Ubuntu did a similar thing way back with libav masquerading as ffmpeg.
How dramatic. I'll ask you as well: any proof for those colorful pictures you're drawing? Or are the people advocating for Rust a convenient target to vent other, very likely completely unrelated, frustrations?
I'm very happy to work with multiple programming languages without getting religious about any of them. They all have drawbacks, Rust included of course.
However, just my mere skepticism about the existence of the "violent proselytizing for Rust" of course immediately had me put in some imaginary group of fanatics. Which is of course normal. People love their binary camps and nuance and discission about merits be damned.
As another data point, I have gone through enough flame wars, incl. the usual ones, and Rust.
There's certainly a fanatic group of Rust developers who really want to eradicate C and C++ from the people's knowledge and all codebases in this universe, so far so openly hating the developers and designers of the said languages.
Same was (or still is) true for some LLVM/clang people w.r.t. GCC.
This is why I use neither.
I'm always happy to discuss PLT and merits of programming languages with neutral parties, even in lively fashion, but when open-mindedness gets thrown out of the window, I do leave the room.
These kinds of healthy discussions will benefit both parties. Hubris, ego, closed-mindedness and fanaticism won't.
Well, I don't see them in HN is what I am saying. Obviously not scanning 24/7 but every time I enter an HN thread where Rust is even loosely mentioned, I brace for the inevitable bullies imagining they are victims. And this thread is exactly the same, sadly.
I am genuinely curious where this fanatic group is. Where are you witnessing them?
> I brace for the inevitable bullies imagining they are victims.
As a person who is bullied physically, verbally and emotionally for years, I'd not throw words bully/victim like wrapping paper like that. Moreover, I'd never bully anyone. I'm not that.
> I am genuinely curious where this fanatic group is. Where are you witnessing them?
Discord servers, mailing lists, issue threads, discussions, here and there. They are very vocal and abrasive minority, but it's enough to make me stay away from them. A special-ops group of these people claim that Rust needs no official specification and they can just ad-hoc develop the language and spec as the compiler evolves, as a side-product of compiler itself (i.e. spec is the compiler).
Last time I encountered them as functional programming fanatics in mid 2000s to 2010s. They successfully made me dislike the community so much that I didn't touch any functional programming language to this day.
Make no mistake: My favorite languages have the same fanatics, and I stay away from them, too. For example, C++ fanatics are an interesting bunch. They don't bully other languages, but new C++ developers who doesn't code like them or the way they like.
Maybe one day I'll start writing Rust, after gccrs stabilizes (they're going well) or really start writing lisp, but I'm sure that I'll never ask a question to a mere mortal about programming in either language.
> As a person who is bullied physically, verbally and emotionally for years, I'd not throw words bully/victim like wrapping paper like that. Moreover, I'd never bully anyone. I'm not that.
I was bullied as well. Knowing karate and aikido helped but not much, those people just hated me for reasons I never quite understood and kept coming in groups even. Some days I wondered whether I'll go back home from school alive. However, me entering middle age has me almost not caring anymore about the reasons they were like that, so I got that going for me which is nice.
I am not "throwing" words. I believe I know what I am talking about because I witnessed a few bullies wisening up to losing prestige and status for being rightfully called out and learning to pretend they are the victims... and it worked in part. It was sickening then, it's sickening now, wherever I spot it. HN is one of those places.
> Discord servers, mailing lists, issue threads, discussions, here and there. They are very vocal and abrasive minority, but it's enough to make me stay away from them.
OK, I'll admit ignorance because I don't go to any of those places or at least it's very rare.
One thing jumps at me: you are avoiding those people which is 100% fair and I would as well. But why avoid Rust itself? Why look down on any rewrite-in-Rust initiatives? Why do you allow yourself be emotionally manipulated? Would you stop believing in your favorite alternative-energy or alternative-engine approaches if they had the 0.1% toxic zealots screaming for attention on events dedicated to those areas?
I can somewhat relate, mind you. One example: I hated how everyone was trying to make me read some book classics and basically made it a point to avoid them just based on that. I was fully aware that was an irrational reaction that was likely robbing me of enjoying good art. I take big pride in myself for finally overcoming this some 2-3 years ago and starting to go through those books. They were nothing special, mind you, and I still couldn't see why people deem most of them classics but at least now my opinion is my own and built with my own two eyes and brain.
> Make no mistake: My favorite languages have the same fanatics, and I stay away from them, too.
Well, that by itself seems to close the discussion. You are aware of this nuance.
> Maybe one day I'll start writing Rust, after gccrs stabilizes (they're going well) or really start writing lisp, but I'm sure that I'll never ask a question to a mere mortal about programming either language.
I refuse to feel shame about wanting to learn and absorb other people's expertise. If somebody is being an arse about it then it's them who are embarrassing themselves; not me. But I do agree it's a waste of time and I'll admit nowadays I start with an LLM session and only then branch out to people if I feel unsatisfied. But that's a function of how awfully busy I am and not that I am becoming more antisocial. (Which also explains I dissociated for 1-2h and preferred to read HN or a book.)
> But why avoid Rust itself? Why look down on any rewrite-in-Rust initiatives?
It's not avoiding, but choosing not to work with it, and it boils down to a couple of reasons. First, I don't work with a language which doesn't have a native GCC frontend. This is part due to supporting GCC & Free Software, and part don't liking rugpulls like license changes and whatnot. My personal weight is beyond negligible in changing outcomes of big currents, but at least I have my principles and stick to them. It's worth noting that I'm not "burning inside" to keep this stance. It's natural for me to do this, and I already like and write C++ and I'm somewhat experienced in that preventing race conditions and memory safety, so that keeps me covered. For smaller stuff I like Go these days. It's a goofball of a language which is very performant and excellent for what it's designed for.
I like to have a tool belt covering a wide gamut of scenarios, and what I use most covers all the needs I have. So Rust is interesting, I don't need it for now.
For the rust rewrites, while I'm not against them in principle, rewriting GPL software with MIT and other permissive licenses is against my values, so I don't support any of them. Writing GPL software with Rust is very possible, and I might do that in the future, but currently I have a couple of heavyweight C++ projects I'd rather work on (in the caliber of material simulations running on HPC systems).
> I refuse to feel shame about wanting to learn and absorb other people's expertise.
My reasons for not interacting with communities are very different. I'm not ashamed of failing, doing mistakes or whatnot. The reasons of I'm tired of interacting with rude people who gets their dopamine from putting people down, so I don't want to navigate all the thorns of the people to get a small bit of knowledge from them. Second, I'm relatively good with reading language references and documentation. I can ingest API documentation with ease and work from first principles.
If required, I can fight the good fight in any arena. I just don't see value of doing it for anything and everything.
In short, I'm not that hopeless to play that game. I'll rather die on hills which are worthy of the fight.
> I start with an LLM session
I don't use LLMs because I don't condone how they are trained, and again reading the reference is much better than a chat interface for me.
> maybe all this should just be thrown away and we should invent an FS with ACID semantics.
You're describing WinFS, which looked into and ultimately abandoned Microsoft 20 years ago. I'm sure other groups have looked into this as well, but there's no such thing as free lunch.
> I'm all for gradual improvements but at one point and on we should zoom even further out and pick our battles well.
That sounds a lot like picking up more battles, yet we all still have 24 hours a day. Recursively trying to perfect lower layers will have you like Hal changing the lightbulb https://youtu.be/AbSehcT19u0
Well, recursively trying to perfect lower layers is what I am advocating for us to not do.
As a guy who prefers to stop and think before coding, to me a lot of the older UNIX / GNU primitives seem broken (like the env vars process inheriting discussion that was here a while ago) and should be completely rethought. I also think people overreact and believe "everything will break". And we have libraries and runtimes that only implement small parts of libc and the deployed apps that use them are running mostly fine for years.
My broader point was: shall we not start breaking away from all this legacy? Must we always rely on corporations to lead the charge?
But yes, I do of course agree with the only 24h a day thing. And likely nobody would want to pay for such a trail-blazing work anyway. Sad world.
If we are going so far to only guarantee correctness if we are using a FS that implements ACID semantics, why not just reinvent the whole kernel and remove all footguns, including memory safety? We could have a OS that each syscall to memory allocation can only be done through safe API.
Otherwise, it doesn't really make sense. The only reason we have things like Rust and other memory safe languages is because we want to create safer programs in the existing imperfect OSes that we have currently.
Yes, this is why I am saying your idea of just reinventing the FS doesn't make sense. You don't get neither the wider ecosystem you get by having an OS compatible with e.g., POSIX semantics nor all the benefits you could get if you reinvent the whole OS.
> The project has the advantage of being old enough for them to be fixed.
That's exactly the point though - replacing established projects is inherently risky no matter how many safety buzzwords the replacement can cram into its GitHub tags.
Maybe the problem is the way we think of dynamic memory. “Oh I don’t know what my maximum size for this is going to be, everything has to be dynamic” Is that really true? Is it really the end of the world for programs to declare maximum acceptable sizes for their inputs, and after that error out or use a ring buffer? If sizes were known you could design around that when using them. Your ram bank is finite, why is every layer inside of it then designed to pretend to be infinite? The rust thing strikes me as a massive waste of time and doesn’t solve the fundamental problem of modeling our programs correctly for reality which is finite system resources, and not just memory. c.f. Chrome loading 4 GB models onto people’s machines.
This is exactly how people thought before 1995. Then everyone started "smashing the stack for fun and profit." In the end, you're trading one set of bugs (dynamic memory bugs and hard to reliably exploit) for another (overflow and easy to reliably exploit).
> Is it really the end of the world for programs to declare maximum acceptable sizes for their inputs, and after that error out
It's supremely annoying when you run into arbitrary limits like that as a user. Often it's like a deliberate expiration date for the software as the world moves on to larger files/etc.
The problem is the lack of talent that is willing to work on this, not the language.
AI Security researchers at least do something. If it was so easy to rewrite everything in rust, I don't know why the response to this incidents isn't a rock solid replacement in rust, the next day.
I tell you why that is. Working on these things doesn't give you stars on github.
That is a very pretentious opinion. Dnsmasq is a ubiquitous project, ~14 years old, and has maintainers that are very experienced in c and in the codebase. Telling them to rewrite in a language they are (maybe) unfamiliar with, even with the help of AI, will make these maintainers' experience worthless.
People seem to think that rewriting in rust just magically fixes all issues, but that's not how it works (See recent uutils CVEs). Rewrites tend to have more bugs because the code is new and hasn't been reviewed as much.
I'm pretty sure we are getting close to the point where a few thousand bucks worth of tokens is enough for an agent coding session to reproduce a significant sized (but not linux kernel sized) C codebase in Rust that's 100% security bug for security bug compatible with the original. And _maybe_ "given enough eyeballs, all bugs are shallow" was true or even close top true once. But non of the "new code" ever has a _single_ eyeball cast over it. You know how sometimes you can stare into the code you wrote for weeks, but as soon as somebody else sees it they go "Hmmm, that bit looks odd. Are you sure it's right?" For most vibe coders or agents coders, it's all the same tool that generated the code that's looking for the bugs - it seems reasonable to assume that if a particular LLM generated the buggy code in the first place, it's at least as unlikely to find the bugs as a human who write buggy code?
> I'm pretty sure we are getting close to the point where a few thousand bucks worth of tokens is enough for an agent coding session to reproduce a significant sized (but not linux kernel sized) C codebase in Rust
Given a comprehensive test suite for the original, probably, yes. if the test suite isn't great, you are still going to spend a lot of time/tokens chasing edge cases.
> that's 100% security bug for security bug compatible with the original
You can do this part without AI. c2rust will give you a translation that retains all the security bugs (and all the memory unsafety). The hope is that the AI in the loop will let you convert it to idiomatic rust (and hence avoid the memory unsafely, and in doing so, also resolve some of the security issues).
> If it was so easy to rewrite everything in rust, I don't know why the response to this incidents isn't a rock solid replacement in rust, the next day.
Meaning that AI/Rust enthusiasts are supposed to supply solutions. Of course they won't.
There is comment like this everywhere, if you don't see them it's just that you don't want to see them. There are a little less frequent than 5 years ago but still frequent enough in each c, c++ or rust discussions.
Which part of the comment comes off as fanatic to you?
I'd disagree with that poster that you can write 100% security bug free code just like that.
> There is comment like this everywhere, if you don't see them it's just that you don't want to see them.
Can you discuss productively without attacks? Mine was, and still is, a question of genuine curiosity. And the only "fanatic" thing in your linked comment is a bogus 100% claim. I'm not seeing fanaticism.
> So you thing someone telling you "look a little harder" is a "personal attack" ? After I took some time to give you a link you ask for ?
If you are taking the time to find a link then understand that your effort can be for naught if you could not resist to insert "if you don't see them it's just that you don't want to see them". What's your imagined ideal outcome when you comment... this, exactly?
Advice: just put the link and skip snarky commentary. Trying to emotionally load your message does not move discussions forward. It puts them in a corner.
> You are the only one using this word in this discussion.
OK, fair -- then I want to hear what words you'd use. Apart from the guy claiming an imaginary "all security bugs will be fixed" which I already said I disagree with, are there other criticisms?
The question is whether the current situation is a short burst of action, and once those most critical bugs get fixed the hype around AI vulnerability scanning will die down, or whether the current crop of system/infra software written in vulnerable languages like C are beyond redemption and they will provide an endless source of critical bugs for AI to find until we fix them by rewriting them in Rust/Go/whatever.
You're likely joking, but in case someone else misunderstands; this is not going to work. Rust with unsafe{} is the only thing you can translate directly to, even with LLMs. Rust with extensive unsafe{} is not something anyone wants to debug or maintain, and is near impossible to improve quickly.
No wonder, VAG has only produced overpriced cars for a while...
I recently helped a friend looking for a brand new SUV in the 70-80,000 euro range (taxes included) and the audi Q5 was both the most expensive and the worst built one in that price range.
We checked loads of cars and agreed that the volvo XC60 was arguably the best value for money, the BMW X3 was the one which drove the best (but also the most uncomfortable), the Lexus NX450h was the most comfortable and the best built, the Mercedes GLC was probably the most balanced one (although the value for money wasn't great).
The Audi Q5 only stood out for poor build quality and being overpriced. It's literally the only car which we didn't see an upside for, we didn't even bother to test-drive it... Also it seems they aren't very reliable anymore...
There is a significant amount of BYD buses here in Spain, I don't live in Madrid but I go every now and then and I noticed a fair amount of electric BYD.
Also this is anecdotal, but I live in a small province capital (<100k citizens) and the urban planning councilor told me most likely most of the new buses we're getting next year will be electric and they'll probably be either BYD or eCitaros.
To be fair I prefer the Chinese models censorship (yes, seriously) because if you ask certain topics they just don't answer instead of giving skewed answers.
My personal and subjective experience is that English is usually better than Spanish (my native language). Unless I'm asking something specific about Spain such as laws, history, etc. I always use LLMs in English.
If you compare a 2012 tesla model s 70D (the most efficient model tesla had then and arguably the gold standard) it had 33.4 kWh/100mi EPA, the 2025 LR is 27.2kWh/100m which is nearly 22.8% less and this while being larger.
What's even crazier is that a tesla 2008 tesla roadster had 28kWh/100mi EPA combined, which is more than today's model S.
Literally there isn't a single combustion car (not including hybrids) which comes anywhere close to this improvement.
Also I don't know about other countries, but I'd argue that in 20 years at least in Europe the fuel economy of diesel cars has gone worse due to emissions, I'm talking about real world usage, regardless of what this WLTP non-sense says.l
The vast majority of vulnerabilities found recently are directly related to being written in memory unsafe languages, it's very difficult to justify that a DNS/DHCP server can't be written in rust or go and without using unsafe (well, maybe a few unsafe calls are still needed, but these will be a very small amount)...