Was just going on a grey-beard rant about how Rust give developers a false sense of security.
I didn't even notice the TARMageddon vulnerability until now and well this grey beard really only can say "told you so".
This is -precisely- the class of bugs I was describing, and -exactly- due to the reasons I outlined.
The blast radius of this thing is also freaking epic, almost anything that used tar in Rust is vulnerable to possible RCEs lmao.
So what were my cautions about Rust?
1. Be careful re-writing old stuff. You will repeat all the 30yr old logic bugs bc Rust is memory safe NOT provable correct.
2. Ppl-power. Lots of rewrites IS dividing our ppl-power. Be mindful of unmaintained core components
3. Vibe coded Rust is just as dangerous as any other language
4. Rust still can be used in memory unsafe ways. You actually have to audit the code to know if they did Rust right.
I've coded in C / C++ / Java / Python / JS and anything else needed to get the job done.
I have never heard any group of devs so quickly dismiss security concerns about their ecosystem as rapidly as Rust devs.
YES the language IS type safe and that's a big value add.
But that value add can quickly be cancelled out without significant attention to detail.
The EXACT same attention to detail I code with in C / C++ / Java / Python / JS etc.
This time, is not different.
It's come to this grey beard's attention today that Cloudflare, one of the largest internet services on the planet, was taken offline worldwide overnight due to a single line of Rust code.
This seems to fall into the exact space where Rust claims to be safer. A real "the compiler should have prevented this" type of bug... yet turns out the compile -CAN- prevent this BUT its a common less than ideal pattern and even the biggest Rust adopters can't get it right.
https://blog.cloudflare.com/18-november-2025-outage/#memory-preallocation
As I keep saying, Rust is a language with a ton of subtle but very important features.
But anyways... here's a 3 year old 24 page blog post on how to write "good" Rust and avoid the exact error CloudFlare hit.
It's written by a long time core contributor.
Reading this, its looks to me to be about as hard to write safe Rust code as almost -any- other type safe language. The learning curve however, is very real AND required.
Shocked to see my opinions on Rust matter this much to people.
If my.... not even dislike.... but caution in the face of hype.... backed up with RECENT & MASSIVE face plants of epic proportions upsets you this much then I don't know what to say other than stay tuned for more Rust coverage.
It's actually critical that new adopters of a technology, especially a highly hyped one like Rust read about the failure modes so we understand how and when to use this tech well.
That's it, that's my ax.
I don't think the discourse is -completely- fucked myself. There's been a lot of concrete and thoughtful explanations of how to learn Rust well and what's going on in some of these failure modes in the comments.
But I'm also seeing a pretty significant defensiveness.
I'd really urge the Rust defenders to take an educational tact rather than a defensive one.
Maybe acknowledge that there IS a learning curve here to get things right and be patient with new comers.
I think its super unfair, not to say you said this, but it seems the Rust defenders are quick to blame the coder for the ergonomics of the tool/product.
I started as a C coder, I loved C... but now I've probably written more .NET / TypeScript/ Python etc than C/C++.
For ALL of those languages there's many great ways to make bad architectures, crash prone code or just plain unsafe systems.
@nullagent The logical extrema of that, which I don't think is a point you're making but is a point I have seen, is that the choice of languages is unimportant because you can write bad code in any language. I think that the other half (again, not a point you're making) is as common prompts people to expect the other half when encountering the first half.
That's not correct, but it is understandable.
Yea I'm strongly in the middle of those extremes.
The selection of language is both important in that yes you must pick and it's hard to change that choice.
But its also largely unimportant in that there are many largely equivalent coding ecosystems so long as you actually pick one that's reasonably good you're likely fine.
@nullagent I think a short version of where we disagree is then likely that I'm quite strongly convinced on the basis of my own experience and expertise at this point that neither C nor C++ meets the bar of "reasonably good."
As noted elsewhere, I can be wrong in that, I'm just one person. One well-informed person, sure, but lots of folks are as well or better informed here. But it's not a view I come to easily or lightly.
Oh dear god.... if someone tells me they are writing a modern project in C/C++ that's not targeting a microelectronic or device driver I'm probably telling them not too lmao.
I don't think I have actually recommended someone OPT-IN to c/c++ in probably a decade.
Now I think about it, I don't think I have ever encouraged anyone to use C/C++.
My ONLY c projects I still maintain are drivers or high performance robotics stuff from a decade ago that I'll be glad when it's Rust.
The reality is that around 90% of new businesses (and I suspect this applies to NPOs & FLOSS projects too) die in under 1yr due to interpersonal conflict NOT technology issues.
So my critics are largely aimed at people who want to start projects, businesses or NPOs.
Don't let the selection of language be your largest debate. You likely have many other fish to fry.
Get a langauge that's good enough and learn it well!
Then, with team work almost any language works.
I don't blame a C coder for NULL ptr mistakes, nor a Java coder for complex catch/throw, or TypeScript hackers for crazy async/await strategies.
It all comes with the language and we will all be the one who writes "bad" code one day.
It feels very "no true scottsman" to cast out any Rust coder who had a bad unwrap/wrap situation as not a "real" Rust coder.
Been seeing a lot of that thought and I think that's toxic. NO that concept IS hard.
And new adopters need help with it!
@nullagent I mean I don't think I've *ever* encountered a defense of C and C++ that doesn't at some point pass through "just don't dereference NULL pointers."
With respect to CloudFlare, most of the arguments that .unwrap could have a better name have come from the Rust side. It's similarly true that no matter what Rust failures may or may not have contributed, code on the critical path for a quarter of the entire internet should not have beginner mistakes *even if* Rust can and should do more.
@nullagent I mean, I don't agree, but fair. I think part of (and I'll emphasize, *part* of) how to help make a discourse where the Rust side is less defensive would be for the C and C++ sides to really deeply examine the downright neoreactionary response to Rust. It's not a good look, to put it mildly.
I don't endorse the defensiveness, and I'm not excusing it, only trying to make the point that defensiveness is an understandable way humans fail when faced with that.
@nullagent yup, and when you do that in C you create memory corruption. In Rust, you get a safe panic, with a backtrace.
There is also extensive documentation, and culture around practicing panic-safety: https://doc.rust-lang.org/nomicon/exception-safety.html
So tell me again how a megacorp's shitty coding practices are Rust's fault again?
@elle @nullagent As a Rust lover, I've said in other threads both that (a) .unwrap is a footgun, at least in the limited sense that it's not as obvious as it should be that .unwrap can panic¹, and (b) that footgun or not, .unwrap is a very well-understood issue in production deployment that damn well should have been caught in review.
___
¹As you note, panic is safe in the sense of not leading to memory corruption or security vulnerabilities, so panicing is still better than null deref.
@elle @nullagent Like, I absolutely hate the whole "git gud" C/C++ attitude of "just don't deref invalid pointers," but for code on the critical path for a quarter of the entire internet, yeah, I'm perfectly fine with "don't deref null."
Even if this was Rust's fault in some sense, CloudFlare absolutely let shit slide in code review, and should be called out on that basis.
@elle @nullagent Yeah, to be precise, I think .unwrap is a bad name for something that can potentially panic, and I hope this gives some impetus to changing to `.or_panic`. That said, as far as potential or arguable footguns go, it's pretty minor. When you learn Rust, you pretty quickly should learn that .unwrap doesn't belong in prod except in pretty rare circumstances.
It's nowhere near the status quo in C, where every * is suspect, but it could have a somewhat more legible name.
@elle @nullagent That, and there's just different standards that should apply at the scale CloudFlare was deploying at.
Does every project need to turn on #![deny(clippy::unwrap_used)]? Probably not. But CloudFlare absolutely should have.
@cibyr @masukomi @nullagent I thought that their other non-Rust implementation had the same 200-entry limit and also failed, in a different way, when given the oversized config. I don't know Rust so I can't evaluate how much of a no-no `unwrap` is or whether that was intentional given their threat model, but I can say that just like CrowdStrike, automation which pushes high-frequency security updates needs to have some *very* *robust* testing and rollback features or a bad update is going to eventually crash your fleet.
if their tool accepted the first 200 entries and then made some very loud log message or if it tested the config before loading it and continued using the old config with a very loud log message then this wouldn't have happened either, yeeting the config directly into prod (because it gets refreshed every 5m) is a core part of the problem.
@nullagent So you're telling me a big corporation failed to correctly audit their code and see if it was handling exceptions?
Sounds about right for Cloudflare, wouldn't be the first time they just quickly pushed something, like that time with the backtracking regex.
@nullagent Rust isn't responsible for a programmer using an unwrap method where they should have handled the error.
> This seems to fall into the exact space where Rust claims to be safer.
In what way does this invalidate Rust's memory and thread safety guarantees? Panics are intentional. The unwrap method declares that the failure case is a programmer error (logic bug) that should throw an exception with a backtrace. If not manually caught, main() will unwind and print the backtrace itself.
From a careful read of the bug reports, the complexity of the garuntees of the rust compiler and the pace of development on production teams... Given all of that context I believe it was a reasonable expectation that the team may have believed they had their rust compiler configured to NOT allow uncaught exceptions like this.
Thus, the intentional pro-Rust hype culture, mixed with a complex build environment imo leads to mgmt believing the team was doing "Rust right" when they weren't
And yes, I think this culture of false sense of security is a very specific failure mode of the Rust community in particular.
And i have yet to see much commentary thus far that shakes me of that belief.
My message is simple, all programming languages take great care. No programming language (certainly one which is not provably correct) will ever deliver on the type of hype which Rust has around it.
Hype alone does not make good code. So you know, tred carefully.
@nullagent I've never gotten the impression that Rust developers have a false sense of security. It is because of security fears that developers are adopting it.
This line of thought is usually used by those who hate the current trend of Rust adoption. It is a way of creating discourse around Rust by trivializing and hand-waving the real world problems that Rust does solve (memory and thread safety) by exclaiming that it is faulty because it doesn't solve all problems. That was never the claim.
@nullagent On the topic of provable correctness, there is no such thing in the world of C or C++. But there is much research and academic papers for Rust via formal verification tools like Coq and Miri.
There is also a lot of related work in extensions to the type system (some of which have already been merged) to extend the capabilities of Rust's type system. So if provable correctness is what you really want, then you can easily achieve that in Rust using solutions like nutype.
@nullagent I'm not sure what you're referring to. The blog post had nothing to do with safety. There is also nothing to configure in the compiler. This is just a case of human error that should have been caught in a code review.
If someone uses an `unwrap()` or `expect()` in a code path where it would logically possible to err, it should have been flagged in a code review. The explicitness of panics and asserts makes code reviews quite trivial. Rust maintainers usually look for these keywords.
@nullagent You have an axe to grind and it’s obvious and silly.
“Safe” means that a program is sound, that the behavior at runtime corresponds to the written code. It does not mean that the behavior corresponds to one’s business needs. That’s not a problem that programming languages can solve.
unwrap() is like assert() in C: its defined behavior is to panic if a condition isn’t met. Here is the documentation:
https://doc.rust-lang.org/std/result/enum.Result.html#method.unwrap
There’s no subtle way to accidentally unwrap when you don’t mean to. The comparison to NULL pointer deref is therefore inapt. If you don’t want an assertion, don’t write one!
I don't have an axe to grind.
I'm just a grey beard who hates hype.
Feel free to get as pedantic with english as much as you'd like to erase the fact that a COMMON Rust mistake took down one of the largest internet platforms the earth has ever seen.
Please take this meme to heartand go touch some grass for real.
@nullagent "It said 'safety razor' on the package, but it turns out I look silly with no beard! Where's the 'safety' in that? Why didn't the razor stop me?" 🙄
I love to start a discussion about programming language safety, the most pedantic topic in the world, and then complain that someone who disagrees with me is pedantic. Touch grass yourself!
@nullagent I don’t know man, I’ve been around the block a few time in the dev community and I feel like dismissing legitimate concerns in favor of vaporware hype is really status quo across the board.
I love rust, it’s what I write when I want to have fun, but as always there’s gonna be a group that can’t seem to distinguish hype from reality.
You ain't wrong. I kinda forget how exciting the new language/tech hype train can be.
My friend's primary gripe with rust as a system language is a social problem.
"The borrow checker handles that" is a conversation-ender. But there are things the borrow-checker does not handle, it uses a memory model that does not map to the reality of out of order execution or non instantaneous cache updates. So he has a few practices he needs people who call his system to use and his teammates always think it's unnecessary.
I've never written a line of rust, but it sounds like that's the exact same conversation with different words happening in multiple places.
@eestileib @nullagent yeah that tracks. What makes it hard is that sometimes Rust really does eliminate problems; e.g., whole groups of value validation tests that I don’t need to write anymore.
This is really cool when it happens, and I think people just get over-excited when they see it.
@nullagent I'd like to notice that what's called "tarmageddon" is demonstration not of #Rust problem, but supply chain problem that affects all open-source ecosystems.
This is a case of long standing bugs in unmaintained crate that too many people use without hesitation.
OK, the matter of #overhype is a different problem and different topic.
@nullagent My personal opinion is #Rust developers aren't serious about security because those same people would've used #Ada before Rust became mainstream, but they haven't. So its pure hype. I'm a big fan of formally verified code and this hype trend is on one hand good – more people are conscious about type safety, but on other hand bad because those very same people tend to completely ignore decades of research on formal program verification.
How many of them know about ATS/Postiats for example or even more mainstream Ada SPARK?
@alg0w @nullagent Fans would do whatever they wish for and asking them to do otherwise is at least wishful thinking.
The fact #Rust doesn't have #ISO standard is IMVHO a blessing - getting anything standardised is a painful process, then #Rust somehow avoided adding nonsense contrary to C++.
Not worries about the license at all - it let #Ferrocene and #AdaCore work on their safety certified products w/o rewriting the whole code.
#Rust could be better w/bounded types, still a lot can be done.
@alg0w @nullagent You can write #Rust programs which do not use dynamic allocation, better stick to `!#[no_std]` what embedded systems do.
Grandpa #C as you called it is a grandpa for a reason. Today people leave universities and haven't seen line of code in C. The pool of potential maintainers for that old code is shrinking faster that I type this post.
@michalfita @nullagent idk, after all those arguments I still think that my point holds: If you *really* care about safe software you write it in #Ada *today*, and not in #Rust someday when it will have bounded types, or stable standard, or being able to recompile your project after 10 years. Safety isn't only about memory allocation it is about processes and first and foremost code maintainers. Most Rust evangelists were JS/Java/C++ programmers in the past – aka normies, so they just don't know anything better.
Rust is a *good* language, but cult following around it is just insane. And all those people that heard about safety for the first time from Rust evangelists... sigh.
P.S. Marketing approach of Rust is worth learning – beat a straw man argument, aka Rust is better then C and ignore real competitors.
P.P.S. And about AdaCore what should they do? of course they want to cooperate I don't get the point.
P.P.P.S. MIT license is only good for corporations that want to abuse free work of open source community.
@alg0w @nullagent I read MIT license as we can do what we want and contribute back as much as we wish. Bindings of #GPL, especially v3 are quite often too strong to risk.
Software freedom fighters (cult similar to one you mention around #Rust) seem to see only one end of the stick, while business sees serious legal risk. If I'm employed I can't contribute to GPLv3 project as this can fall under consideration as part of my work, then my employer is at risk.
MIT doesn't imply ceding any rights.
@mmstick #Ada was specifically designed to prevent from "human error" - syntax is quite verbose and it is difficult to do code golfing. Second, I don't think that modular types can be *elegantly* encoded in Rust, or arrays that can be indexed by value that makes sense for the domain – you can index an array with values from -30 to 10 just as an example. And a lot more. Type system of Ada is hard to replicate. Also for truly paranoid there is Ravenscar profile – it is very difficult to write programs in it (I did it, it was tough), but it is the closest thing to "if it compiles – then it works".
Rust is *good* but preaching – isn't.
@alg0w Never said that Ada doesn't use syntax to prevent human errors. Ada is one of many influences that shaped Rust's design. Both use static type systems, have explicit concurrency, and support message passing.
But as a general purpose language, Ada is too cumbersome to use. Thus why you rarely see it used. Rust was an academic project for a full decade before it went stable. When it pivoted into this direction, a lot of work went into solving usability. Learning from the past, it succeeded.
nullagent
Cassandra is only carbon now
Raven667
SMT
Lady Errant
elle
Cassandrich
Eric Vitiello
masukomi
cibyr
Orange Lizard Girlthing
Michael A. Murphy 
Ben Rosengart
Nate Cox
eestileib (she/hers)
Fernando
Michał Fita
alg0w