Not a fact. Particularly in the embedded world, crashing is preferable to malfunctioning, as many embedded devices control things that might hurt people, directly or indirectly.

> If a pacemaker stops — telling a victim “but the memory was not corrupted in the crash” is a weak consolation.

If a pacemaker suddenly starts firing at 200Hz, telling a victim "but at least it didn't crash" is a weak consolation. A stopping pacemaker is almost always preferable to a malfunctioning one, as most people with pacemakers still have sufficient natural rhythm to survive this for long enough to get help.

> We actually had a recent Cloudflare outage caused by a crash on unwrap() function

Please read the whole article. If the unwrap hadn't caused an exit, the process would've run out of memory, leading to a much less deterministic behavior which is much harder to diagnose and fix. I always prefer an early exit with a clear error instead of getting killed by the OOM reaper.

> Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time.

Yeah until that memory safety issue causes memory corruption in a completely different area of code and suddenly you're wasting time debugging difficult-to-diagnose crashes once they do start to surface.

> We actually had a recent Cloudflare outage caused by a crash on unwrap() function: https://blog.cloudflare.com/18-november-2025-outage/

There were multiple failures before that `unwrap()` and the argument can easily be made that this is no different than an unchecked exception or a release assertion.

> Sync/Send, Mutex and reference counting (Arc)? Unfortuantely, those lock or simply mess with CPU caches badly, so they are inefficient for multithreaded communication, at least an intensive one. They are safe, but inefficient. Which kinda destroys the first uncompromising thing in Rust — performance.

Doing this the "correct" way in other languages has similar impact? So I'm not sure why Rust forcing you to do the correct thing which causes perf issues is uniquely a Rust issue. Doing this the "just get it done" way in other languages will likely come back to bite you eventually even if it does unblock you temporarily.

There are plenty of times I did a `static mut` global in Rust just to get some shit done and oops, accidentally hit some UB as the project grew.

Without trying to evaluate a claim about which is more "complex", since that's somewhat subjective (even if I do have some feelings on the matter), I can pretty definitively state that the vast majority of the concurrent code I've written in Rust has not used Arc<Mutex<T>> at every single step (and I don't think I've _ever_ used `Arc<Mutex<Box<T>>`, which would be like having `std::shared_ptr<std::mutex<std::unique_ptr<T>>>` in C++). It's totally valid to argue that the learning curve for Rust is sharp, but I don't think they've made a great case for it here generally rather than just for their specific experience. This even further implied by the idea of a "language switch"; I've been programming Rust for a decade, and I only learned C++ after learning Rust, so from my perspective, I'd have to "switch" to C++ from Rust, and it seems similarly pointless to do so. (I understand my experience is probably atypical, but that's kind of my point; everyone's perspective is different, and I don't think that making an argument based almost entirely out of subjective personal experience speaks very well to a "core problem" in a language unless you can speak to why that's representative of the general experience most people have, and I don't think they've done that here at all).

Oh boy, this is going to be the new thing for Rust haters isn't it?

Yes, unwrapping an `Err` value causes a panic and that isn't surprising. Cloudflare had specific limits to prevent unbounded memory consumption, then a bad query returned a much larger dataset than expected which couldn't be allocated.

There are two conclusions: 1) If Cloudflare hadn't decided on a proper failure mode for this (i.e. a hardcoded fallback config), the end result would've been the same: a bunch of 500s, and 2) most programs wouldn't have behaved much differently in the case of a failed allocation.

- Compile speed. Why do people care so much? Use debug for correctness and iterating your code. You're hardly going to change much between runs, and you'll get an incremental compile. Let rust-analyzer tell you if there are errors before you even try compiling. Let your CI do release optimization in its own time, who cares if CI is slow?

- The cloudflare bug was not caused by rust. Every language needs some way to say "hey this thing is invalid", and that's what happened when the list of AI tools got too long (or whatever their business issue was). Making the app panic was a design choice, not a language choice. Every language has a way to not handle errors.

- Things having unsafe {...} does not make them unreliable. On the contrary, if you run into a memory issue in a rust program, you know where to look for it. The problem in c++ was that the whole program was unsafe, and you then had no way to narrow it down. Memory safety errors are like type errors: a large class of errors that are worth checking for. If you're writing good c++, you have a linter that checks similar things anyway, and if you're disciplined, you've also upgraded warnings to errors. FWIW, I do think the marketing over-emphasizes memory management, because there are a lot of these hard learned lessons that are default in rust but optional in c++.

- Mutable shared state: make bad designs hard to write. Mutable shared state is another one of these eternal bug sources. Use channels and pass messages.

Honestly, it reads like a lot of critiques of Rust: people haven't spent enough time with it, and are not over the learning curve yet. Of course everything is cumbersome before you're used to it.

This is not objective. You're entitled to your opinion, but I at least am fine with compile times the way they are. For it to be objective, it would have to be something that is true independent of your or my opinion, but ultimately this is a subjective matter.

> Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time.

This is a completely baseless assertion; Rust does not "crash all the time". If a programmer chooses to crash rather than keep going when the program is in an unforseen state, that is his choice, not something the language requires. Presumably that programmer feels that crashing is beneficial (because it helps to make bugs obvious sooner), but you aren't required to do the same.

I am more concerned about correctness and "zero-cost abstraction" of the end result, if sacrificing few seconds of compilation time is necessary for that - fine by me.

> It’s complex. Just as complex as C++. But C++ had legacy and Rust had not. The complexity of forcing your way through the jungle of Arc<Mutex<Box<T>>> on every single step directly impacts the quality of the logic being implemented i.e. you can’t see the forest for the trees. Once again, C++ has the same problem, so what’s the point of the language switch in the end?

So, you seem to prefer data races and dangling pointers, or? Have you tried "actors-like" channels+rayon approach if you hate mutex so much?

> Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time.

You again prefer UB and/or corrupted state (and call that "reliability") over required explicit checks of Result via matching. This is definition of bad code to me.

> When handling lots of mutable shared state (GUI, DB, stateful services, OS/hardware), the performance of native Rust memory model is subpar

Few boundary checks sometimes add negligible overhead, but again you need those in any language to enforce correctness, Rust just adds those automatically.

D language smiling in the corner [1].

"D supports Ownership and Borrowing, just like Rust. DMD, D's reference compiler, can compile itself in less than 5 seconds, thanks to a fast frontend and fast backend. D is easy to metaprogram through traits and templates. You can make your own JIT in D with dynamicCompile." [2]

[1] Kevin James meme creator tries to guess why the photo went so viral:

https://www.yahoo.com/lifestyle/kevin-james-became-internets...

[2] Ask HN: Why do you use Rust, when D is available?

https://news.ycombinator.com/item?id=23494490

> Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time.

Would you prefer silent UB/memory corruption in Cloudflare case? I don't think most developers would agree with this.

This is not the language problem, but its simply the nature of the problem no? It is like saying, full adders are complex, can't we design something simpler? No, full adders are the way they are because addition in binary is complicated.

What you are saying is that this problem is not your kind of problem, which is fine. Not everyone needs to face the complexity of optimizing full adders. And so we created abstractions. The question is, how good is that abstraction?

C++ is like using FP math to do binary addition.

Memory safety and thread safety are causes of heisenbugs. However there are other causes. Rust don't catch all heisenbug. But not being perfect doesn't mean it's useless (perfect solution fallacy).

The article has some valid points but is full of ragebait exaggeration.

Personally my biggest complain from Rust is that I wish it was more readable. I've seen function signatures that seemed straight out of C++.

This is incorrect in a way that honestly feels insulting. It's not the language's fault that you called the `crash()` function—every language has a way to terminate execution, and for good reason. Crashing isn't even necessarily incorrect behaviour; that's how you pass the error up to the infrastructure layer for handling. The problem here existed at a system design level, not a language level.

For the author to paraphrase this (bad) critique like this:

> You cannot get 99.999% reliability with Rust — it crashes all the time.

is outright dishonest and insulting to me as a reader.

It's true that it's easier to write correct async code using immutable shared data or unshared data.

However, it's very hard if not impossible to do fast and low memory concurrent algorithms without mutable shared state.

Yes C++ has many many issues, and yet most of the biggest most complex software systems in existence are written in it. I don't see the browsers, OSs, DAWs, AAA games etc. being implemented in Go. Rust is a real improvement for these areas, with a proven track record of making software more reliable and maintainable.

If the author intended to say "Rust is not the best programming language for every problem" they should have said that but it would have been worth an article as much as "Screwdrivers are not the best hammers".

doing that first when setting up an rpi is a good way to not only grab a bunch of useful programs like exa and bat, but it also functions as a nice benchmarking and stress test tool. i can check my heatsinks and fans, and grab a smoke and a coffee, while cargo compiles an app that concatenates a file with syntax rendering

Uptime isn't reliability; it's producing predictable behavior. Allowing indeterminate ("malfunctioning") behavior is the opposite of reliability.

> People create lies to gain power and money. Which is kinda what I was supposed to do, but for random reasons I went rogue and chose sanity instead.

> I am anti-bullshit.

These "contrarian for the sake of being contrarian" vibes naturally flow into this Rust post. Rust has a ton of faults, but this is was a very shallow critique.

Rust attempts to solve this trifecta and that is where the complexity arises. If the problem at hand does not need async, then Rust has done commendable progress in dealing with the above trade-offs.

Async is in Rust can be hard because the problem it is trying to solve is hard.

All the above may be fine but when it comes to choosing the language in practice we need to think of trade-offs and guarantees that are suitable for problem at hand.

There is a reason why C++ reigns supreme in HFT and Gaming as memory safety is not super critical.

Disclaimer: I like Rust.

But it is NOT a good general purpose language. And, maybe to be putting words into the author's mouth, that is their main beef. That every seems to be pushing "Rust All Things" even when it makes no sense, and even if there are much better alternatives available.

So for such comments as "so what about compile time", the issue is that for some, compile time _is a concern_. If it isn't for you, great. But you just can't discount what are valid concerns for others.

People seem to forget that languages are _tools_, and as such, have different sweet-spot use-cases.

It's still quite rough around the edges, but Crystal is a fun choice for this type of thing. If you want a readable high level language and sane package manager that compiles to reasonably performant machine code, it's worth a look.

Node JS has had vulnerabilities in the past: https://www.cvedetails.com/cve/CVE-2021-22940/

Go is also not Memory safe: https://www.ralfj.de/blog/2025/07/24/memory-safety.html

Grrr. Clueless people keep saying that. People have been verifying programs for over forty years now. Formal correctness in terms of not violating assertions is possible for most useful programs. As someone pointed out about the Microsoft Static Driver Verifier, if you're program is anywhere near undecidability, it has no business being in the kernel. This not a legit criticism.

Had to buy a new laptop because of this.

I don't think this is correct, strictly speaking. Furthermore, I think this conflates two common causes of slow generic compilation:

- Type-checking them can take a lot of time

- Generics may be implemented in a way that generates a lot of code

Neither of those are required for generics-heavy languages (e.g., OCaml is generally considered to compile fast despite having a "complex" type system), and the presence of one doesn't necessarily require the other - a hypothetical "simple" generics system with heavy use of monomorphization can end up taking a long time to compile, and a "complex" generics system that erases types may take a while to type-check but could compile fast after that.

> Put a non-optional borrow-checker on top of it

From my understanding the borrow checker usually takes up a small fraction of the time needed to compile. There are cases where that's not true, but I think people tend to overestimate its impact on compile times.

> There are ways to implement unsafe programs that still don’t execute remote code or leak secret — they only corrupt user data and act sporadically.

Reliably implementing unsafe programs that don't have RCEs or leak secrets but still corrupt data and "act sporadically" seems like a very peculiar combination of requirements to me, if it's even possible. "Act sporadically" is also quite nebulous, and depending on the precise issue may in fact be an RCE or secret leak in hiding - after all, it's not that uncommon for exploits to start their life as someone noticing a crash.

> It’s probably the strongest point of my whining: Rust is memory safe and unreliable. The price of memory safety was reliability in addition to the developer’s sanity

I think that is actually one of the weakest points. I didn't see any support for a claim that memory safety necessarily requires trading off reliability, let alone that that is what Rust does.

> Step into the shared mutable state — and there a memory corruption is not an exception, it’s a rule. You have to handle the corruptions, you cannot simply crash.

What definition of "memory corruption" is being used here? I didn't think that's the kind of thing that you usually "handle"...

> Which kinda destroys the first uncompromising thing in Rust — performance.

I feel this misunderstands Rust's priorities. (Safe) Rust prioritizes safety over performance, and that has been a well-known tradeoff for basically its entire lifetime. If you want performance at the expense of safety, that is what `unsafe` is for.

> So, to reiterate, the second you step into the shared mutable state you lose every single advantage of Rust. Which is kinda rational considering that the main concept of Rust was to never employ a shared mutable state.

This misses another useful bit of Rust, which is the ability to contain unsafety to clearly-delimited sections of your codebase.

There's more I could say, but life calls...

> Its compilation is slow.

I agree on this. But you can get better hardware, split a large code base into several crates, optimize for fast compilation when developing. On the other hand, I feel the guarantees of Rust compilation are discounted. If your code is more correct before deployment, wouldn't that save you debugging time later?

My biggest issue is with macros. I like them (and LLMs are good at writing macros) but they make both compilation and LSP ridiculously slow.

> It’s complex.

No, it is not. There is a learning curve. But after a while, you just alias your "Arc<Mutex<Box<T>>>" and name it something you understand (mypipedtype) and then just fly over the abstractions. There is sunk time to build/architecture your complex type but I see that as investment that can save you time later.

> In fact, for many applications malfunctioning is better than crashing

What does malfunctioning mean? Leaking your secrets? Compromising your system? Corrupting your data/state? I'd take crashing any time of the day.

> When handling lots of mutable shared state (GUI, DB, stateful services, OS/hardware)

This is a problem until the whole stack becomes Rust. If you are using lots of extern/FFIs in your code, I really sympathize with your position and you are kind of in a worst of both worlds situation.

How is `T` broken? How are the other things broken?

No matter what language you use, most of the code running between what you wrote and the hardware will be written in C. Your choice for the 1% on top is not very consequential. There is still a huge attack surface area no matter what.

This complaint is nonsensical. If your Rust program panics, it’s because things are fucked up and it’s not possible to safely continue. The alternative is to continue unsafely, which will fuck things up even more.

The Linux kernel does the same thing. If it encounters an error, it panics.

A quick search of HN shows a bunch of articles, "X is a disappointment," which aren't flagged. Do folks have such thin skin about this topic that expressing disappointment deserves flags?

The author dismisses these defects, but try telling a financial institution that it's "only" corrupt user data when the books don't balance. Explain to an aerospace company that acting sporadically is just fine.

Yeah, just another data leak, no biggie.

On the one hand, I don't regard it as a real "problem" because as the post says, it's by design and the design is that you pay the compilation cost but in return you get something valuable from it: fast safe code. So you pay a fixed cost to compile during development and it's your users and future you who get the benefit of future performance and stability. This is why Rust users are usually okay with it, because the more you use Rust, the less you pay for the compile times.

On the other hand, I'm sitting here now 20 minutes into building a random Rust project I found (I believe it's AI vibecoded so I won't link it). It's only 3000 lines of Rust code... I honestly cannot fathom why it's taking so long, because I have a codebase of 100kloc Rust with more dependencies and lots of macros, and that takes only about 2 minutes to compile from scratch. But apparently, some people/machines can write Rust so bad that 3000 lines takes 20+ minutes, and that's just not good at all for Rust.

So whereas the slow compilation times are by design, I think perhaps if my daily experience were 3kloc taking 20 minutes to compile, I wouldn't ever use Rust. So I'm wondering if that's how some people's experience with it goes, leading to the disparity of opinions. I kind of want to figure out why this particular project is taking so long to avoid whatever trap the AI coded itself into

(aside: this is another problem with AI that I hadn't thought about yet... a human programmer would have noticed the rapidly ballooning compile times and corrected for them before they got absurd; whereas the AI writes it all at once and doesn't factor how the code impacts compile times. So it maybe be technically correct, but also pathological).

Then I discovered that C++ has a very cool feature that Rust doesn't have: jobs.

Now, I no longer search for Rust positions.

One thing that this blog doesn’t address though, is the cult-like following of Rust. It’s like the “AI” of oss — a main selling point by itself despite not being a feature. Seemingly, there is an assumption that software written in Rust is inherently better than any other, or that if something is written in Rust, it cannot have any errors.

Sure, new software should be written in it instead of C. But why fix programs that are already memory safe?

Refactor your build.

>It’s complex. Just as complex as C++. But C++ had legacy and Rust had not. The complexity of forcing your way through the jungle of Arc<Mutex<Box<T>>> on every single step directly impacts the quality of the logic being implemented i.e. you can’t see the forest for the trees. Once again, C++ has the same problem, so what’s the point of the language switch in the end?

If you can come up with something better, write a macro for it.

>Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present. You cannot get 99.999% reliability with Rust — it crashes all the time.

Learn the language a bit better, use code coverage tools, and write better tests.

>When handling lots of mutable shared state (GUI, DB, stateful services, OS/hardware), the performance of native Rust memory model is subpar, and non-native unsafes just leave you with slow compilation, high complexity, and no memory safety in the end — which makes Rust practically meaningless for heavy mutable state jobs.

True for C++, too, if you don't implement things properly.

> Its compilation is slow. I mean SLOW. Slower than C++.

No way. Maybe Rust 1.0, but it's steadily improved and it's definitely faster than C++ now.

> It’s complex. Just as complex as C++.

True, but the problem with C++'s complexity is that you have to memorise all of it or you'll accidentally invoke UB. It's so complex that is basically impossible.

Rust is complex but most of the time the compiler will tell you if you got it wrong. There are exceptions of course (lots of async footguns) but it's still night and day.

> Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing

Not sure I really need to counter this...

> When handling lots of mutable shared state (GUI, DB, stateful services, OS/hardware), the performance of native Rust memory model is subpar, and non-native unsafes just leave you with slow compilation, high complexity, and no memory safety in the end — which makes Rust practically meaningless for heavy mutable state jobs.

Not totally clear what he's getting at here. Maybe the ergonomics of GUI style programming which are still being figured out? Hardly a deal breaker though is it? There are plenty of C/C++ GUI libraries with terrible ergonomics and the only one that is actually great (Qt) had to use a custom language extension for decades to achieve that.

> So, is the Rust bad or good? It’s neither. It’s a mediocre programming language with thousands of man-month put into its development

I would love to hear what he thinks a good programming language is, because I can easily pick more holes in any other language than he has.

This anti-Rust zealotry is super tedious.

> Rust sacrificed sanity and practicality for memory safety

skill issue