Several core problems with Rust

Yes, but in C++ we would simply not have asserted the result has_value instead of has_error and instead returned some implicit memory corruption. Or, I think that is the author's argument. (I don't subscribe to that point of view.)

I tend to disagree.

- 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.

"Memory corruption vulnerabilities" != "concurrency bugs" or even data corruption. The last thread I was in about this, someone pointed to Go segfaults and said "see! memory corruption!" (obviously: no).

An easy response to claims like this: there's a huge tower of software written Go at this point, including the entire K8s ecosystem. Show me the memory corruption exploits.

Rust has its issues and there are plenty of things to not like about Rust, but this article is giving me the impression that this person has not written much Rust. Unfortunately, many such cases with Rust criticism.

> 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.

He hates on C++ pretty much the same as he does on Rust. Your argument seems to be that Rust is better than C++, which is akin to trying to make the case that Cholera is better than Smallpox.

Language wars are boring and pointless, they all have areas of suckage. The right approach is to pick whichever one is the least worst for the job at hand.