> In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present.
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.
Something else I usually don't see: A system hitting a fail-safe is a lot easier to detect and handle from the outside than one that just enters an unknown invalid state.
Like, if the rule were "Always-Keep-Running" then hospital equipment power supplies wouldn't have circuit breakers that cut the power when something is wrong. But cutting power seems lot easier to detect for the backup power supply so it can fully take over.
it's funny because I have seen the opposite.
Engineer: "it crashed because it dereferenced a null pointer"
boss: "add null pointer checks everywhere!"
... and because it used "if" instead of "assert", it made the null pointer arg a valid argument, making it a tolerable state of the running software, which displaced the locus of crashes far from the source of the issue. Moral of the story, use "assert" to make it crash as early as possible and debug THAT. You want to restrict the representable states in the software, not expand them by adding null checks everywhere.
Yeah, the blog post is a very confused write-up. I saw lots of similar posts on LinkedIn recently, with quite a lot of likes and echo chamber comments. It’s just hilarious how a narrative emerges that reinforces biases due to ignorance. There must be a name for that sort of fallacy.
I love to write in Rust precisely because I can express failures more explicitly, it’s the transparency that wins here.
I’d frame the issue Cloudflare had rather in the PR review and QA corner, maybe as some AI complacency. But it’s not a problem with Rust.
Also stopping is a state which definitely might happen anyway and must be planned for. The pacemaker's wires can be dislodged or damaged, power sources fail, these things will stop the pacemaker regardless of how much you love the "just keep going" approach to software engineering. Which means medics have already thought about what they're going to do when this happens to a patient, and "The software failed" just goes on the same list as "10 year battery only last 8 years" in terms of undesirable but hardly impossible scenarios which constitute a medical emergency.
> 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.
Strong agree on this one, usually embedded systems are designed to "fail safe" on crash - the watchdog will trip, and hardware reset will put everything in a deterministic, known safe state.
What you want, above all else, is not to fall into undefined behavior. That's the beauty of `unsafe`, it bounds UB into small boxes you know to test the hell out of.
It's honestly mind boggling how people react to this. Rust turns unknown failures in C and C++ into known failures and suddenly the C/C++ people start caring about the failures, but attribute the failure to the new language, even though the same failures are secretly lurking in their C/C++ code bases. It's kind of like trying to silence a whistleblower.
>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.
I am running into an undiagnosable CUDA "illegal memory access" problem in vLLM, a code base that is a mix of python and CUDA (via pytorch). At a certain load something appears to either overflow or corrupt the memory and vLLM restarts, which takes a minute, because it has to reload several dozens of GBs into memory and then rerun the CUDA graph optimizations.
The pacemaker argument is complete nonsense, because the pacemaker must keep working even if it crashes. You can forcibly induce crashes into the pacemaker during testing and engineer it to restart fast enough that it hits its timing deadline anyway. Meanwhile a silent memory corruption could cause the pacemaker to enter an unknown state where the code that runs the pacemaker algorithm is overwritten and it simply stops working altogether. Having a known failure state is a thousand times more preferrable to an unknown number of unknown failure states. Critical sections (mutexes) and unsafe code has to be panic free (or at least panic safe) in Rust, so the concept of writing code without panics isn't exactly a niche concept in Rust. For every panic based feature, there is usually a panic free equivalent.
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.
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.
>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.
Some very solid argument here. However, as already implied in my article, you can get most of the guarantees without losing your sanity. Memory-safety-related problems are important, but they are not the sole source of bugs in applications — as developers of Zed found out.
>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.
It might be counterintuitive, but garbage collectors in multithreaded code can be very efficient. I mean you just spawn lots of objects with random references in between and then eventually GC untangles the mess — it's zero overhead until the GC cycle. Escape analysis and semantic-reach containers can reduce GC work a lot (so you don't have the classical JVM GC problems). More specialized things like RCU and general quescence-state reclamation can be totally pause-less.
> Some very solid argument here. However, as already implied in my article, you can get most of the guarantees without losing your sanity.
I think this is part of why your article is causing a strong reaction from a lot of people; quite a lot of the justification for your point of view is left implied, and the concrete examples you do give about Rust (e.g. `Arc<Mutex<Box<T>>>>` and `.unwrap`) are hard not to see as straw men when plenty of people write Rust all the time without needing to rely on those; it turns out it's also possible to get more reliability out of Rust for those people without losing their sanity.
Most of the opinions you give are hard to distinguish from you personally not finding Rust to provide a great experience, which is totally valid, but not really indicative of "core problems" in the language. If you instead were making the argument of why you don't personally want to write any code in Rust, I don't think I'd have much criticism for your point of view (even though I wouldn't find much of it to apply to me). Then again, the article starts off with a statement of previously having made an intentionally provocative statement purely to try to compensate for a perceived bias in others, so maybe I'm just falling for the same bit by trying to engage the article as if it's serious.
Also the argument with `Arc<Mutex<Box<T>>>>` boils down to "Rust makes it hard to work with automatic reference-counted shared mutable heap-allocated state." In which case... mission accomplished? Rust just made explicit all the problems that you still have to deal with in any other language, except dealing correctly with all that complexity is such a pain that you will do anything you can to avoid it.
Again, mission f#*@ing accomplished. Maybe you DON'T need that state to be shared, reference-counted, or heap allocated. Maybe you can refactor your code to get rid of those annoyingly hard to deal with abstractions. And you end up with better, more reliable, likely faster code at the end of it.
So many times I've tried to do something in Rust the old fashioned way, the way I have always done things, and been stopped by the compiler. I then investigate why the compiler/language is being so anal about this trivial thing I want to do.. and yup, there's a concurrency bug I never would have thought of! I guess all that old code I wrote has bugs that I didn't know about at the time.
There are basically two reactions people have to this situation: (1) they're thankful that they learned something, their code is improved, and go about their day learning something new; or (2) feel frustrated and helpless that the old way of doing things doesn't work, and rage-quit to go write a "WHY RUST IS THE WORST THING SINCE MOSQUITOS" blog article.
Yeah, this pretty much summarizes my experience. In most situations, the actual information I need to share between different contexts is quite small, and using a channel ends up being pretty clean. There are still times I need an actual reference counted wrapper around a mutex, but they're the exception rather than the norm, and even then, there are often ways you can reduce the contention (e.g. if `T` is a type you can clone, and you only need a snapshot of the current state of the data rather than preventing changes while processing based on that snapshot, you can just clone it, drop the mutex guard, and then proceed without needing to worry about borrows).
It is hard to use because you can’t just access the shared state. You have to annoyingly lock it, handle the guard object, etc. Each one of those layers has protocols.
Of course you have to lock a mutex. You'd have to do that no matter the language, right?
And that's what I meant by verbose/ugly. Each of those steps is usually an if let / else error. None of those steps are hard, but you have to do them every time.
Heh. You're pedantically correct, the best kind. I meant "have to" in terms of "for correct operation you must" not "the compiler forces you to" since the latter isn't a thing in some languages.
> So many times I've tried to do something in Rust the old fashioned way, the way I have always done things, and been stopped by the compiler. I then investigate why the compiler/language is being so anal about this trivial thing I want to do.. and yup, there's a concurrency bug I never would have thought of! I guess all that old code I wrote has bugs that I didn't know about at the time.
This is also my experience. I've had dozens of times over the years that I've been confused about why Rust does something a certain way, but I don't think I can recall a single one where I didn't end up finding out that there was an extremely good reason for it. That's not to say that in every one of those cases, the design choice Rust made was the only reasonable one, but in the cases where it wasn't, the situation always ended up being more nuanced than it appeared to me at first glance, and what I would have originally expected would have implicitly made a significant tradeoff I hadn't considered.
I'm having trouble finding it now, but years ago someone had a quote that ended up getting published in the language's weekly newsletter that was something like "Rust moves the pain of understanding your program from the future to the present". It's extremely apt; most of the difficulty I've seen people run into when trying to program in Rust ends up being that they're forced to consider potential issues that in other languages they could have ignored until later, and then would have had to debug down the line.
There’s a handful of pain points that the Rust model does impart which are not fundamental. For example, unsafe code is required to get a mutable borrow to two different fields of a struct at the same time.
But really that’s the only example I can think of offhandedly, and I expect there are not many in total. Nearly all of the pain is merely the trouble of thinking through these issue upfront instead of kicking the can down the road.
The only other one I can think of is kind of poor ergonomics around "self-borrows"; it's a lot less common than I've felt the need to mutably borrow two fields from the same struct independently, but there have very occasionally been times where I've realized the simplest way to structure something would be to have one field in a struct borrow another. This is somewhat hard to express given the need to initialize all of the values of a struct at once, and even if you could, there are some complications in how you could use such a struct (e.g. not being able to mutate field `a` safely if it's borrowed by field `b`). Overall though, the things that Rust prevents me from handling safely because of its own limitations rather than them being fundamentally unsafe are quite rare, and even with those, they tend to be things that I would be quite likely to mess up in practice if I tried to do them in a language without the same safety rails.
>However, as already implied in my article, you can get most of the guarantees without losing your sanity.
Yeah sure, but what compares that gives you similar perf, safety, and language features to Rust? I'll use "safety" in a loose term to say "you really infrequently encounter odd memory safety issues". Go for example still has the occasional memory corruption issues with maps in particular although these don't show up too often and the race detector exists.
C# is probably the closest I can think of for AOT? I don't really know what the deployment story for a .NET application looks like these days though.
Go has some language design things that turn people off.
>but they are not the sole source of bugs in applications — as developers of Zed found out.
You called out Zed in the blog post as well but I've not seen the Zed devs expressing regret of using Rust. Is this just an assumption on your part? As someone who's written many UI applications with egui and one with GPUI, I've felt some minor pain points but nothing show-stopping.
I used to write a lot of C#. I used to write a lot of Go. I now write either and basically exclusively write Rust these days and a bit of C/C++ at work. The only time I've really felt the pain of `Rc<RefCell<...>>` gross types was recently when trying to port a game engine's data loader to Rust. It makes heavy use of OOP patterns and trying to emulate that in Rust is asking for a bad time, but I did it out of just out of trying to one-shot the migration and keep logic similar. Not fun, but I knew what I was getting myself into.
>Yeah sure, but what compares that gives you similar perf, safety, and language features to Rust?
I've already answered it in the original article — Rust is already here, and better language is not. Still, it will not make me say "it's the best option we have by now" — because it's not nearly the best option.
Performance? Lots of code is cold and not impacting performance much. You just don't need everything written in Rust or C++.
>You called out Zed in the blog post as well but I've not seen the Zed devs expressing regret of using Rust. Is this just an assumption on your part?
I'm kinda saying if I was a Zed dev I would have my pillow wet with tears at night. I know this because I participated in IDE development in C long time ago, and I was drowning in this whole low-level stuff all the time, I just could not do a single feature because I have to handle hundred of those other small things before the feature can work.
>As someone who's written many UI applications with egui and one with GPUI, I've felt some minor pain points but nothing show-stopping.
I have no idea what those applications were and how complex they were, so I cannot comment on it.
> It might be counterintuitive, but garbage collectors in multithreaded code can be very efficient.
It is indeed. But on the flip side, no other programming language is going to give you a compile error if you forgot to wrap you data into a mutex before sharing it between threads, and you'll either end up with a ConcurrentModificationException exception at runtime (Java) or with an undefined behavior.
But otherwise yes, there are plenty of situations where a GC is a totally valid solution. Just not for most of Rust's niche.
> It might be counterintuitive, but garbage collectors in multithreaded code can be very efficient.
What has garbage collector to do with multithreaded code? Once you have two or more threads which needs to share data, they need to sync and you'd end up using some kind of lock, which will affect the performance. GC doesn't make anything efficient or less efficient here. It might make the code simpler as you don't have to worry about allocation/deallocation, but I don't see how it's magically going to remove the lock.
> 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?
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).
> We actually had a recent Cloudflare outage caused by a crash on unwrap() function
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.
And one of the fun things about how unwrap() does that automatically, is that if you are working with an orchestrator with retry logic, you won't need to (re-re-re-re-re-)write your own for the entire program - the orchestrator will see the error, log its output, and try again in high volume workloads, or move on to the next request - this is incredible and nice to use especially when a failure in one request doesn't need to fail the entire application for all requests.
I shy away from unwrap() in almost all cases (as should anyone!) but if you are running a modular system, then unwrap when placed strategically can be incredibly useful.
Yet they spent ages trying to determine the actual cause of the failure, according to their postmortem, so I'm not sure what the advantage you're positing is?
Doing a naked unwrap() in a function that returns a Result is probably a crime against humanity. Like, this is the dumbest thing you could possibly do.
It has potential to be the new thing, since several details synergize to make this incident more powerful:
1. Previous claims that Rust code often just works after compiling.
2. Previous claims that low-level error-handling idioms like matching, using Result, etc improve code reliability.
3. Previous claims that using unwrap in example code is ok for brevity. Also, Rust developers would know not to use it in production code.
4. The fact that significant portions of the internet were taken down because a production unwrap from a big, mature player and one of the Rust early adopters.
Sure, Rust is not the problem here, but rather Clownflare being too big and not having their SRE processes fully up to par for their size. Perhaps they are simply too big to operate at the needed level of reliability.
However, Rust anti-fans can easily ignore the above and simply press the issue and debate the minutiae of error handling, human reliability, etc. It’s surprisingly effective and might even catch the ear of management.
However, this article is overall not at the level expected of Rust anti-fans in 2025. I commend the author for trying, but they need to improve in several areas like providing iron-clad real-world examples, proving the required level of experience, focusing more on pain points like dependencies and the potential for supply-chain attacks, addressing reskilling issues and internal corporate politics, etc.
There was a blog by a veteran Rust game developer a while back which single-handedly destroyed the enthusiasm for Rust in gaming. That is the gold standard of Rust criticism for me.
1. But the code did just work after compiling. The code said "This can never be an Err, and if I'm wrong, you are allowed to panic." And it did just that.
2. They do. If you use them, which they didn't.
3. It is. Let's not discard personal responsibility.
4. The error would've happened in any language, Rust debatably made it easier to find though.
I don't write Rust code myself because I simply don't write any code that requires this kind of reliability, and thus I haven't expended the effort learn it properly. But if I were to start such a project, I would still go for Rust and learn it properly. I also don't have a "favorite" language. I just pick whichever seems most appropriate for the project, any decent programmer should be able to pick up any non-esoteric language to the point of adequacy in a few weeks anyway.
.unwrap() was a huge mistake. It should be banned from release builds outright. It's the equivalent of dereferencing a null pointer in C or the NullPointerException in Java. All .unwraps() should be replaced by .expect("uniquely identifying message") immediately and preferably the compiler checks that the expect messages are unique within a crate and issues a warning. Debug builds should by default give .unwrap() and .expect() a tiny chance, like 0.1%, to trigger anyway, even when the Option is Some (opt out via configuration).
To my knowledge, the only difference between `unwrap()` and `expect()` is that the latter takes a custom error message, whereas the former generates a generic error message. In both cases the resulting error message includes the filename and line number of the panic. Both can also generate stack traces if you set `RUST_BACKTRACE=1`, unless this was explicitly disabled at compile time.
So if you want to ban `unwrap()`, then you should probably also ban `expect()`, and make sure to handle all possible cases of Err/None instead.
> Debug builds should by default give .unwrap() and .expect() a tiny chance, like 0.1%, to trigger anyway, even when the Option is Some (opt out via configuration).
I'm trying to understand what you're proposing. Are you saying that normal debug builds should have artificial failures in them, or that there should be a special mode that tests these artificial failures?
Because some of these failures could cause errors to be shown to the user, that could be really confusing when testing a debug build.
>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.
So why do they need Rust then? What advantages does it provide? That was the main point of the article — we all wanted a better language, but got another crappy one instead.
> So why do they need Rust then? What advantages does it provide?
That Rust didn't prevent one error in one specific instance does not mean that Rust didn't prevent any errors across any instances. Nor does it mean that Cloudflare didn't benefit from Rust in some way(s) elsewhere.
For example, from one of Cloudflare's previous blogposts [0] (emphasis added):
> Oxy gives us a powerful combination of performance, safety, and flexibility. Built in Rust, it eliminates entire classes of bugs that plagued our Nginx/LuaJIT-based FL1, like memory safety issues and data races, while delivering C-level performance.
In Go, if one would ignore the error, it could result in a panic or the program would continue with some unexpected state. Go projects work on an honour system and either return Nils with errors or empty structs.
The move to Rust was partly motivated because it prevented that entire class of errors. No more out-of-bound reads, or data races. The compiler audits these missed spots.
Now, you could say a managed memory language would suffice as well. Perhaps it could. But we needed performance, and no memory-managed language met those performance needs then or today.
I get you're making the case that Rust isn't perfect for all use cases, but Cloudflare's scenario is the exact corner case your argument falls apart in: we needed fast and safe in an environment where not being fast or safe had real business consequences, and nothing else except Rust gave both.
That Rust produced a predictable and deterministic way of failing, while in C++ the equivalent code of accessing an uninitialized value without verifying it beforehand would have resulted in entirely unpredictable behavior whose reach is entirely unbounded.
Moreover, now they realize this is an issue for them, they can just do "Ctrl+F unwrap" and fix each instance. Then they can put a hook on their commits that automatically flag any code with "unwrap". In some languages where you're allowed to just ignore errors, you could fix the proximal bug, but you'd never be sure you weren't causing or ignoring more of the same in the future -- how do you search for what isn't there?
- 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.
Yeah. Rust’s Option::None as like null in C++. Unwrapping an option is like checking if something is null and crashing. This "crash from an unwrap" is just a null pointer exception / segfault in any other language. The same bug would be trivial to write in any other language, and with more or less the exact same result. Its just - weirdly news because it was rust code. What?
> 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.
Exactly. I’ve spent years with rust and my complaints are very different. Well, I still wish it compiled faster but all the other stuff is noobie problems. As someone with more experience, my frustration points are things like how async blocks do compiler magic you can’t write yourself. I hate unnameable types. I think Pin is confusing and weird. And the syntax for interacting with raw pointers is unnecessarily inconvenient and ugly.
Yes, rust makes programs with a lot of shared mutable state awkward to write. So don’t program like that. In general, if you write code in language X as if it were a bad version of language Y, you're going to have a bad time. The right question here is if the "rust way" of thinking about your code results in a beautiful program. You can't answer that if you go in with too many preconceptions of how programs should be designed.
Rust makes it very, very easy to .unwrap() something, making panic-crashes the default error handling behavior for a lot of rust programmers. But it does this without, e.g., Erlang's reliability services that will auto-relaunch code that crashes. The end result is NOT a very good user experience.
I say this as a Rust advocate and daily Rust programmer, btw.
When it comes to distributed services, unwrap is likely the behavior you do want, because the service is being run by a scheduler that detects failures, and a panic would be tied to a metric and page an sre. My read of the situation is that they were overwhelmed by their dashboards which made it harder to identify the root cause, but that is a common situation for these kind of events. I'm pretty sure that this exact sequence of events will never happen again to them because they will adjust their observability to be clearer, should this ever happen again.
For libraries and cli tools, you don't want panics except for things that are broken beyond any recovery. A cli tool should not panic directly, instead emitting human readable errors.
The Cloudflare bug was unwrapping a Result::Err not an Option::None.
Both Option and Result can be unwrapped and - to some extent not coincidentally - both can also be subject to the Try operator (?) which is arguably more correct here than unwrap because this can fail and perhaps the caller will have some plan to recover.
My list of peeves would be very different from yours. I would like to prohibit move of the dodgier as casts (requiring that you write out the conversion call you actually meant explicitly and then handling any edge cases) for example.
What sort of "interacting with raw pointers" are you thinking of that's too inconvenient and ugly for your liking?
> Both Option and Result can be unwrapped and - to some extent not coincidentally - both can also be subject to the Try operator (?) which is arguably more correct here than unwrap because this can fail and perhaps the caller will have some plan to recover.
If someone wrote code like that and the program crashed, nobody would attack Go or C. In all these cases (including rust), the programmer is expressing clear, explicit intent for the program to panic if the call failed. I've seen some people say .unwrap() should be named .unwrap_or_panic() or something to make that more clear? I dunno. It seems like a nothingburger to me. A buggy program crashed. They'll do that.
> What sort of "interacting with raw pointers" are you thinking of that's too inconvenient and ugly for your liking?
I have 2 complaints. First, I wish Rust had a -> operator or something like it. This sort of thing is horrible:
(*(*(*ptr).foo).bar)
Secondly, rust's aliasing rules make writing pointer heavy code very difficult. I like to run my unsafe code through MIRI to make sure I'm not doing anything bad, and its incredibly subtle.
Here's an unsafe function which manages the internal state of a skip list:
This code is insanely fragile. There are multiple pointers to different elements floating around. The only way I got miri to calm down was to dereference the node pointer constantly. Eg:
*cursor.num_bytes -= (*node).str.len_bytes();
let next = (*node).first_next().node;
Basically everything else I tried caused obscure aliasing problems. I think if I rewrote this code today I'd probably use a Vec and safe rust instead. I can much more confident write correct C code than correct unsafe rust code. I wish it were the other way around.
As a general principle, unsafe rust should be as simple and easy to reason about as possible so we can spot security problems. But rust's syntax makes unsafe code very complex. I don't think this complexity is in any way necessary.
I see what you mean for -> although personally I haven't missed it (I spent many years writing C) I don't write much pointer twiddling in Rust so I'm the wrong person to have an opinion.
However surely the aliasing is actually a problem and so MIRI is annoyed because what you wrote might be wrong? If we hang on to (*node).first_next() but somehow node changes, we're no longer talking about the same thing, it's exactly the aliasing problem.
I'd have to (which I have not) examine in detail how your code works to offer an opinion beyond speculation, but I think my instinct is sympathy for the "Don't write aliases" approach.
> I think my instinct is sympathy for the "Don't write aliases" approach.
Yes, requiring that nothing alias it’s much more conceptually elegant. But as I said, in practice it makes programming extremely treacherous. There are no warnings when you alias. No errors. 99% of the time you’ll get a working program with no bugs every time you build. You’re just - quietly - at the whim of llvm. Maybe it won’t compile correctly on some other architecture. Maybe a minor compiler bump, or different flags, will make your program totally broken. The only way to discover there’s even a potential problem is by running the code through MIRI.
I get why it’s like this but I think it’s a mistake. I think unsafe rust should be at least as expressive and pleasant to work with as C. Having quiet foot guns here seems antithetical to rust’s philosophy of safe ergonomic programming.
Err, you can't use `?` with `Option` unless I've really missed a big feature somewhere. You'd have to map it to a `Result` then unwrap, but at that point you still need to define an error type.
I guess you've "really missed" this feature or more likely you are considering only the case where our function signature says we return Result and so early returning Option won't compile.
Because the modern "try v2" operator is a trait, it is implemented for Option, Result, and ControlFlow plus Poll variations.
Historically its ancestor the try! macro was provided only for Result, but that's a very long time ago now.
I guess? If it's still languishing in nightly I'm not sure I consider it usable; I'm aware some people are fine to run nightly but I keep to stable releases.
So, all of Try is unstable. This means your stable Rust isn't allowed to implement Try for your own custom types, however the syntax is stable, so since Try is implemented for all of Option, Result and ControlFlow, those all work with the ? syntax even though that implementation is marked unstable.
Let me give you another example you've probably used without realising it, when you write password.contains("foo") in Rust. Why can you write "foo" there? Rust doesn't have overloading, and yet you can pass strings, characters, and functions including lambdas - how can this work? They all implement core::str::pattern::Pattern, an unstable trait used to deliver this functionality for all string matching.
In fact mechanically what's happening here for Try is that ? always worked for Option and Result, the "try v2" feature isn't about the syntax at all, it's about the behind the scenes implementation of that syntax. But that's not important, the syntax is promised and the final implementation will almost certainly be tryv2 or something very similar.
I guess? If it's still languishing in nightly I'm not sure I consider it usable; I'm aware some people are fine to run nightly but I keep to stable releases.
Ardour is a real-world, mid-size project. About 1.3M lines of code, almost all of it C++. On the fastest typical x86_64 systems, it builds in about 1.5mins, on an M3 it builds in about 3.5mins, on a somewhat older x86_64 16 core system it builds in about 7.5mins.
If you ever touch libs/ardour/ardour/session.h or libs/pbd/pbd/stateful.h, you're in for an almost complete recompile. If you touch libs/temporal/temporal/timeline.h, same thing. That's just the day to day work of being a developer of a native desktop application - nothing to do with CI or releases.
Your point about compile times is very dismissive and wrong, but I agree aside from that. It's worth noting that the Rust team explicitly tracks, monitors and limits regressions in, and actively optimizes for compile times, and Rust community surveys always ask for better compile times. This is clearly a significant issue, and while Rust is never going to compile as fast as C or Pascal, it can and will improve so that it becomes more usable.
Wrong, it makes good designs easy to write with clear safe APIs. If you know what you are doing just create a safe wrapper over unsafe functions and do what you need.
For example you can just write a lockless triple buffer for efficient memory sharing and wrap the unsafe usage of pointers with a safe API. now you only need to pay attention to those specific unsafe calls.
It encourages good designs but it does not make them easy to write, but that's somewhat the point. Its not trivial to design a safe API that pushes performance limits.
> just write a lockless triple buffer for efficient memory sharing and wrap the unsafe usage of pointers with a safe API
This isn't practical or pragmatic.
And I say this as someone who likes rust and develops in it every day.
> - 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?
Even if you know you're code compiles, it's often easier and faster to validate the logic or complex interactions by running the code. In large (and even not so large actually) projects, debug builds can be painfully slow, even on good hardware. It's important to have a tight feedback loop so that you can interate quickly.
>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.
What's the largest Rust-based public codebase so far? Rustc with like 1 million lines of code including all the dependencies in all the languages? Zed IDE has 800k lines. Incremental compilation seems to work fine at this scale, but things become messy above it. Most people prefer to not exceed the limit.
>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.
People think BEAM (Erlang/Elixir) does not have shared mutable state because the programming model says so, but it actually has some mutable shared state transparently under the hood i.e. implementation details and runtime. BEAM processes all run in a single OS address space, they are not even separate threads but async tasks spread out across OS threads — and still per programming model of the language those are "shared nothing". So in the end BEAM is a very good abstraction on the partially shared mutable state.
And no, in BEAM remote messaging is not nearly the same as local messaging. For example, you don't have built-in supervision trees on remote, and ETS is also local-node-only.
I do agree that hardware model of shared mutable state is inherently problematic, but we don't have other commodity CPU-s yet — you have to handle the shared mutable if you wanna be close to hardware.
>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.
Well, at least you confirm that the complexity is real. Don't get my criticism to close to the heart though — I did exaggerated the problems a bit, because someone needs to counteract the fanboys.
> 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
This isn't true, no matter how much people keep saying it. Unsafe does not scope bugs to the block, or even where you have to look for bugs. Just having unsafe in your codebase means changing code outside the unsafe block could cause UB.
Doesn't mean I think it's worth complaining about, there's really no better way for Rust to do this without sandboxing memory.
This is very true from outside an encapsulation, but within the private implementation of a type there may be safe Rust that's required to uphold some assumptions made by the unsafe Rust [if there is some] and while in theory the bug is in the incorrect assumption made by the unsafe Rust in practice we're going to fix the "safe" code which broke our assumption instead.
Nope. I would encourage you to actually read what unsafe does, because nowhere in the Rust docs does it say "scopes bugs to the unsafe block"
See the below code. The unsafe code is doing exactly what it's supposed to. The safe code frees a value while it's being used. This compiles. There's nothing to change here in the unsafe code.
```rust
use std::slice;
// Unsafe block that creates a slice from raw parts
fn make_slice(ptr: *const i32, len: usize) -> &'static [i32] {
unsafe {
slice::from_raw_parts(ptr, len)
}
}
fn main() {
let vec = vec![1, 2, 3, 4, 5];
let ptr = vec.as_ptr();
let len = vec.len();
// Unsafe block creates the slice - this operation itself is fine
let slice_ref = make_slice(ptr, len);
// Safe code: drop the vec
drop(vec);
// Safe code: use the slice - CRASH/UB
println!("{:?}", slice_ref);
}
The unsafe code is not fulfilling the contract of "unsafe", which requires the coder to uphold the memory safety rules as seen from outside. make_slice is putting a very wrong lifetime on the slice it returns.
My whole comment here is that safe code has to care about how it uses data from unsafe code. That's pretty evident from my example and from reading from_raw_parts. How would you fix this by only editing the code inside the unsafe block? Because you said the problem is the lifetime. That's outside of the unsafe block.
> The unsafe code is not fulfilling the contract of "unsafe", which requires the coder to uphold the memory safety rules as seen from outside
It's the exact opposite. From the Rust docs. [1]
> By calling an unsafe function within an unsafe block, we’re saying that we’ve read this function’s documentation and we take responsibility for upholding the function’s contracts
The caller here is what is violating the contract. It's not the unsafe code's job to do that. How could it? It's just making a slice, it doesn't know what from. It can't guarantee a slice it makes is ANY kind of lifetime. If it could, it wouldn't require unsafe.
We don't have to use a static lifetime to have this bug:
// still broken
// basically says it has SOME kind of lifetime
fn make_slice<'a>(ptr: *const i32, len: usize) -> &'a [i32] {
Lifetime annotations are just annotations for the compiler, but they mean very little when using unsafe. I wrote a bad lifetime to illustrate that Rust doesn't care. Normally, the compiler would make sure your lifetimes make sense, but not with unsafe. Because it's the calling code that has to care.
Yes, if you change the function signature and require it to receive the vec so you can see the lifetime, you could technically fix it from this function. That's the only way to get the right lifetime.
So yes, as long as you change your function so much you can basically remove unsafe, you can fix it from the function.
But you can't do this in scenarios where you'd actually want unsafe, like FFI, custom data structures, etc. You don't have the same lifetime information available to you.
> The caller here is what is violating the contract.
"The caller" of the unsafe function is the unsafe block in make_slice. And yes it's violating the contract.
> How would you fix this by only editing the code inside the unsafe block? Because you said the problem is the lifetime. That's outside of the unsafe block.
If it's locked into returning a static lifetime, then the only fix is to return a slice into a static allocation.
Is this the functionality you wanted? Probably not. But an unsafe block having an awkward API isn't an excuse to violate safety. Sometimes the only answer is to say no. Calling from_raw_parts this way is a clear bug.
> How could it? It's just making a slice, it doesn't know what from.
It could know more if you added more to the unsafe block outside the call to from_raw_parts.
> It can't guarantee a slice it makes is ANY kind of lifetime. If it could, it wouldn't require unsafe.
> as long as you change your function so much you can basically remove unsafe, you can fix it from the function.
from_raw_parts exists for situations where the coder can guarantee that the lifetime is valid (no matter what safe code does), but the compiler can't guarantee it (because it's not smart enough).
It's not there for situations where you make the safe code promise to behave.
It does have a lot of uses, in places that do need unsafe. You just happened to make an example that doesn't need it.
The mere ability to "use it incorrectly" and break memory safety is evidence of a bug. Safe rust in a program without unsafe can't use anything incorrectly in that way. Safe rust in a program with appropriately careful unsafe can't use anything incorrectly in that way.
> The lifetime is outside of the unsafe block.
The unsafe block uses the types from the surrounding function, so you can't change those types without double checking the unsafe block is still valid.
> I can change it from static and we still have the same bug.
Change it to something correct and have the same bug?
Because your continued examples look like no. If you make the lifetime arbitrary then it's still messed up, and if you get the lifetime off the vec then the bug is fixed.
> How would you fix this by only editing the code inside the unsafe block?
In this case, the solution is to mark make_slice as unsafe. This should make sense if you think about it for a second, because it's a thin wrapper around an unsafe function. If it were possible to make a function which did what std::slice::from_raw_parts does safe, it wouldn't be marked as unsafe.
> It's the exact opposite. From the Rust docs.
The docs you quote say the exact opposite of what you claim. Where do you do call the unsafe function in an unsafe block? In make_slice, not main.
> So yes, as long as you change your function so much you can basically remove unsafe, you can fix it from the function.
The actual use case for std::slice::from_raw_parts is for when you control the pointer and length and thus can guarantee that they're valid (specifically, by encapsulating them and making sure no safe functions can get them into an invalid state). For example, std::Vec::as_slice uses it [1] to get a slice from the pointer to it's managed buffer and it's stored length.
> FFI
There are two possible ways FFI could cause memory safety violations despite being called from safe code:
- The safe wrapper makes incorrect assumptions about the contract of the functions it's calling (e.g. maybe it assumes that a c function returns a pointer which it's the caller's responsibility to free, but is actually freed by the c code). In this case, the bug is in the unsafe rust.
- The foreign code violates it's contract (e.g. same as above, but the documentation of the c code claims otherwise). In that case, the bug is in the foreign code.
Either way, the memory safety bug is not in safe rust.
> The actual use case for std::slice::from_raw_parts is for when you control the pointer and length and thus can guarantee that they're valid (specifically, by encapsulating them and making sure no safe functions can get them into an invalid state)
Right...so you fix it from the safe code, because the safe code is in charge of using from_raw_parts correctly.
> Either way, the memory safety bug is not in safe rust
This might just be a difference of semantics between us, but I really don't see how you can arrive at that conclusion. Just remove the function entirely and let's use from_raw_parts directly. The bug is literally not in unsafe, it's when we drop the vec after making a slice from it. To fix this, we would not change anything in unsafe.
let vec: Vec<i32> = vec![1, 2, 3, 4, 5];
let ptr = vec.as_ptr();
let len = vec.len();
let slice_ref = unsafe {slice::from_raw_parts(ptr, len)};
drop(vec);
println!("{:?}", slice_ref);
> Right...so you fix it from the safe code, because the safe code is in charge of using from_raw_parts correctly.
Safe code cannot corrupt the Vec variables to make Vec do something incorrect.
> To fix this, we would not change anything in unsafe.
You're supposed to.
Some coders might implicitly count the rest of the function as trusted code that's part of enforcing the invariants of the unsafe code. So there's an implied "unsafe" block that fills up the rest of the function, as far as responsibility goes.
I won't argue one way or the other on that philosophy, but if anything outside the function with the unsafe block is part of enforcing invariants, then that is clearly wrong.
If you subscribe to that philosophy, then you could say the drop is the problem in this single-function case. But in the original the bug is still inside make_slice, because make_slice is unleashing a fragile and uncontrolled slice into the safe world of main.
(There might be some more subtleties when it comes to class API boundaries but I don't want to dig through that right now, it's not relevant to the important part of this conversation.)
>> To fix this, we would not change anything in unsafe.
> You're supposed to.
To me, it just sounds like we're disagreeing on definitions. You can view it as unsafe corrupting the vec, I don't disagree with that, but it's the way the safe code coordinated the unsafe code that caused that problem.
I'm happy to be shown a different way. Would you kindly show me how you would fix this in the unsafe block only?
> Some coders might implicitly count the rest of the function as trusted code that's part of enforcing the invariants of the unsafe code. So there's an implied "unsafe" that fills up the rest of the function, as far as responsibility goes
That's essentially what I'm arguing.
> but if anything outside the function with the unsafe block is part of enforcing invariants, then that is clearly wrong
What is clearly wrong? I'm not saying none of it is wrong, I'm just saying unsafe allows you to make bugs outside of it. And yes, it can happen at arbitrary depth, not just in the function containing unsafe code.
> Would you kindly show me how you would fix this in the unsafe block only?
I'd probably hold a reference to the vector or something.
> That's essentially what I'm arguing.
The thing is it's only the safe code in the same function as the unsafe block that you could call responsible in any reasonable sense.
In the original version the main() code cannot be blamed for dropping a vector 'early', because it didn't invoke this scheme that requires the vector to be kept alive, make_slice did. It was make_slice's responsibility to guarantee the underlying allocation stays alive, and it didn't do that.
> What is clearly wrong? I'm not saying none of it is wrong, I'm just saying unsafe allows you to make bugs outside of it. And yes, it can happen at arbitrary depth, not just in the function containing unsafe code.
If you're putting responsibility on code in the same function, you're not really treating it as safe code. There's an unsafe{} around the entire function body that you should have written if you were going for maximum clarity.
If the depth goes any higher, you screwed up. It should be impossible for safe code outside the function to use your code and cause a memory error. If it's not impossible then that's a bug in the unsafe blocks (or the function with the unsafe blocks).
> I'd probably hold a reference to the vector or something
In a way that only changes the unsafe block?
> make_slice's responsibility to guarantee the underlying allocation stays alive, and it didn't do that
We çan talk about the simpler code example. How can my unsafe block make sure an allocation stays alive past the unsafe block itself?
> If you're putting responsibility on code in the same function, you're not really treating it as safe code. There's an unsafe{} around the entire function body that you should have written if you were going for maximum clarity
I'm not talking about what should've been done, I'm saying this is something to be aware of on projects with multiple people who may not catch something like this. People think bugs cannot happen in safe code. I just showed it happening. The bug was not in unsafe, or in the drop, it was in println.
> How can my unsafe block make sure an allocation stays alive past the unsafe block itself?
Put it in another data structure or something?
Listen, if you can't make the invariant work, then you need to change the function. An unfixable unsafe is not an excuse to allow errors
> I'm saying this is something to be aware of on projects with multiple people who may not catch something like this.
It's good to be aware but put the blame in the right place. It's the unsafe code that's actually at fault. If you are seeing corruption, look at the unsafe code first with an adversarial mindset.
> The bug was not in unsafe, or in the drop, it was in println.
N. O.
Any unsafe code that outsources invariant enforcement that affects memory safety to safe code has bugs. There's wiggle room on "outsources" but that's the only wiggle room.
I think one can argue make_slice is in fact at fault here since it's unsound (i.e., it doesn't enforce the requirements of from_raw_parts() and so allows safe code to invoke UB) and therefore either should be marked unsafe or should actually enforce the requirements of from_raw_parts().
That being said, I think in this context that's more of a nitpick since you're right in stating that bugs that result in UB need not be scoped strictly to unsafe blocks.
Internal use of unsafe requires securing the safe code at the module boundary. However, the design of unsafe still greatly reduces the burden of memory safety, both when it is and isn't used directly. The specific semantics of Rust aside, unsafe is more or less the ideal way for a language to express unsafe escape hatch constructs.
If the goal is to make a safe abstraction, which is what I'm talking about, proper use of visibility and safe code at the module boundary encapsulates the unsafe code soundly.
You seem to be talking either about improper encapsulation or unsafe that is intended to be exported and used unsafely. Or perhaps some method that is not sound according to the language.
This is true. If you consider unsafe memory to be a separate region in Rust, your safe Rust code can still have pointers to unsafe memory. The only solution to this problem is to perform some sort of validation of the returned data structures every time they are returned by an unsafe block.
You really have to compare articles like this, which are just a bunch of hand waving around the author's biases, against articles with more concrete statements like the Android team finding a 1000x reduction in memory vulnerabilities compared to C/C++. Thanks for your opinion but I'm going to weigh the people who actually use the language more than you.
For my reality of developing for smaller projects than Android, I will absolutely weight Android team's opinion less than the opinion of smaller projects.
Trying to mimic FAANG engineering practices is a fools endeavour that ranges between naiveness at best and CV padding at worst.
The author says "Rust crashes all of the time" and then goes on to invoke the Cloudflare unwrap() as an example of that. Uhhhh... but that was clearly a programmer error, right? Ignoring the possibility of a Result being Err instead of Ok is not something the language is supposed to protect you against.
By coincidence I was talking to one of Cloudflare's engineers this weekend† and they actually argued that the unwrap() isn't the problem per se, that instead it's just wrong to go from "We don't know if this data works" to "Everything is broken" without the step where you check that data works - and that's still true if we're doing this once per minute not once per month.
I argued that requiring expect("expectation") calls rather than unwrap() instils the discipline to consider what you're expecting and thus why you think we won't panic - to write the text in the expect call, but I did not convince them and they remained sure that what Cloudflare needs is better deployment discipline not improved engineering practices.
† It is a coincidence that they work for Cloudflare, it was quite intentional that I spent much of my weekend with them, we were playing video games.
Screw discipline, it’s a tooling problem. Making canary rollouts with automatic rollback the default would take a lot of investment up front, but then would make discipline at release time a non-factor.
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.)
Yeah, I don't really get that argument if that's what the author is trying to claim. If there's a language where a programmer mistake can't have bad consequences, C++ isn't it, so either it would need to be combined with an argument that C++ programmers are just better (which seems like a bold claim that would require evidence, on top of not really being about the language anymore), or it isn't really a point against Rust.
There are programming languages/models/runtimes that crash and recover, there are models that gracefully degrade. Rust cannot recover. Neither can C++ in many cases e.g. when you have an exception in a destructor then it's a guaranteed `std::terminate`.
Do note that C did not have such a flaw built into language — C++ authors invented it and Rust inherited this flaw (the authors simply did not feel like it's a flaw). I mean specially designed embedded C code can survive total RAM erasure and still perform some meaningful work (with CPU registers and ROM intact). Or compare it to BEAM that can have processes crash all day long and still continue to work. "Memory safety at all cost" is not a practical requirement — it's theological.
> e.g. when you have an exception in a destructor then it's a guaranteed `std::terminate`.
You can throw in a destructor [1]. You just need to mark that destructor noexcept(false). You do get a guaranteed std::terminate if an exception escapes a destructor while unwinding is already underway, though.
> Do note that C did not have such a flaw built into language
assert() says hi?
> I mean specially designed embedded C code can survive total RAM erasure and still perform some meaningful work (with CPU registers and ROM intact).
Why doesn't a similar argument apply to "specially designed" Rust?
> Or compare it to BEAM that can have processes crash all day long and still continue to work.
Again, nothing stops you from writing Rust that does the same.
>You can throw in a destructor [1]. You just need to mark that destructor noexcept(false). You do get a guaranteed std::terminate if an exception escapes a destructor while unwinding is already underway, though.
Come on, please tell me you don't do this in your code. Formally you are correct, but there are many things in C++ that should have better not existed.
>Why doesn't a similar argument apply to "specially designed" Rust?
Because it would lose most of the Rust properties by that time. C code with fixed memory layout, on the other hand, is ideomatic and was widely employed in the past. It's still being employed in embedded. I'm not saying that you are wrong though, there might be people optimizing Rust for this very purpose, but I'm not aware of such an effort.
>catch_unwind exists for a reason.
>>Or compare it to BEAM that can have processes crash all day long and still continue to work.
>Again, nothing stops you from writing Rust that does the same.
Who's gonna GC the poisoned garbage left in undefined state after the crash? I'm not saying it's impossible — I honestly have no idea whether safe recover is possible in Rust, but from what I know it's rather in middle of "not possible" and "not viable".
> Come on, please tell me you don't do this in your code.
I don't, but that's not to say that I think it should never be done.
> Formally you are correct, but there are many things in C++ that should have better not existed.
Sure, but I think it's important that one should do their best to be correct and/or precise.
> Because it would lose most of the Rust properties by that time.
Perhaps for specific bits of code, but that doesn't necessarily require that your entire codebase give up on safety. Part of Rust's value is in isolating unsafe stuff to specific sections of your codebase both so the rest of the code can make use of Rust's guarantees and so if/when something goes wrong it's easier to pinpoint the problem.
Not to mention if you're talking about "specially designed" codebases in the kind of situation you describe you're almost certainly not in pure-C-land either (e.g., standard C doesn't have the concept of CPU registers, so if you really need to stick to what's in registers you're going to have to resort to compiler-specific extensions and/or assembly). If you're willing to allow the necessary extensions for C, it's only fair that you do the same for Rust.
> I'm not saying that you are wrong though, there might be people optimizing Rust for this very purpose, but I'm not aware of such an effort.
There's a reason no_std exists. Low-resource embedded use has been a design focus since well before Rust's 1.0, and those considerations have continued to influence its evolution since - for example, Rust's async design is the way it is specifically to ensure it is usable in limited-resource environments.
> Who's gonna GC the poisoned garbage left in undefined state after the crash?
Whatever supervising process/thread you write/designate, if that kind of recovery is important to you? I don't think there's anything about Rust that precludes you writing such a thing.
Not to mention, must there be "poisoned garbage" in the first place? I don't think it's strictly necessary that such a thing be produced after a crash even if you ignore the fact that part of the reason unwinding exists is to clean things up even while crashing.
> but from what I know it's rather in middle of "not possible" and "not viable".
I'm curious how you came to that conclusion. It seems wrong both on a theoretical level (Drop/unwinding/catch_unwind should obviously suffice for at least some cases?) and on a practical level (tokio can recover from worker thread panics just fine?).
> Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times.
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.
> Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times.
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 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:
I am not too familiar with D, but it seems that D's borrowing system is somewhat different than Rust's, given that it is not the focus of how D is implemented and used. This means different design tradeoffs.
There are appropriate ways to contrast D with Rust and illustrate where D is stronger, but it is inaccurate to say "Rust has borrowing; D has borrowing" and conclude that they are comparable in this sense.
>"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."
Indeed, there are languages that have generics, compile blazingly fast, and still have good runtime performance. Go lang is another good example, although not perfect too. If only Rust designers did a single thing to make it compile fast instead of "eventually".
"Generics" is not why Rust compiles slowly. Rust had certain design decisions and implementation details that impact compile times significantly. Do not misrepresent them and pretend that the Rust developers are incompetent or malicious. By doing so, you invite discourse as ideological and uncritical as that of Rust fanatics, however many or few there are.
>Do not misrepresent them and pretend that the Rust developers are incompetent or malicious.
I'm sorry, but I sensirely think the Rust designer did a sloppy work by reimplementing C++ flaws with a new syntax. The history repeats itself, the same pathological mechanism once driving C++ development now drived Rust — I mean large enterprise wanting to change everything without changing nothing, the new tool that would feel like the old tool. They did not really invent some new model, look at std::shared_ptr, std::mutex, move semantic — it was already in C++ before the prototype of Rust. The "share immutables, lock mutables" model was a holy grail of C++ concurrency caused by the way STL worked — and STL is not nearly the only container library in C++.
Okay, what's your take on why exactly Rust compiles slowly?
Rust certainly takes after C++, but it's not the same. It's more like C++ if it was made today. For instance, Rust's destructive move semantics are the better default. (However, Rust making everything moveable by default is a bit of a drawback.) I don't understand your point about std::shared_ptr, std::mutex, and the immutability/mutability model. These are not C++ constructs; they are general programming constructs that C++ has an implementation of. Rust does not claim to have some innovative take on reference counting or locking. However, Rust's borrowing is an improvement (by default) on managing shared mutable state. Rust is not Carbon, or whatever new C++ variant is out there; it is a backwards-incompatible language that offers better ways to do many of the things C++ is used for.
> Okay, what's your take on why exactly Rust compiles slowly?
I think one interesting thing that could be explored more is what aspects of Rust "inherently" result in slow compilation (i.e., if you changed said aspects to improve compilation speeds then you end up with a "different" language, assuming some hand-waviness with respect to equivalence here) and what aspects are practically and/or theoretically improvable.
For example, rustc's reliance on LLVM for optimization is a well-known source of sluggishness, but I wouldn't classify that as "inherent" since Rust could use a different backend that works faster (e.g., Cranelift) and/or be more efficient about the IR it emits. Something like monomorphization, on the other hand, is a more in a grey area since it's (as far as I know) essential for Rust to meet its performance goals, but IIRC it's not out of the question for the compiler to implement generics using a different strategy instead, which might be viable as an opt-in tradeoff.
There are at least three separate things that rustc and cargo could do to significantly improve compilation speed, but they are complex engineering efforts that require time and engineers being paid to work on full-time. They are: doing what zig does to compile only items that arr reachable, which requires making rustc reentrant to stop after name resolution and cargo more complex to pass used paths through subsequently, leveraging an incremental linker and have rustc only codegen the binary patch instead of the whole binary and have the linker calculate the patch, and caching proc-macros and treat them as idempotent (likely as opt-in). There are of course others, like pre-compiled distribution, better intra-rustc parallelism or feature cfg handling, but those have more open questions and require additional design work before I could claim they're attainable.
Oh, I hadn't heard that you guys are looking at Zig-style "targeted" compilation (for lack of a better phrase). That sounds like it entails quite a bit of infrastructure work. Is there a GitHub issue I can follow to keep an eye on progress?
Out of curiosity, have there been any interesting pondered/proposed avenues for speedup that were rejected because they would result in too much breakage, violate a core tenant of Rust (e.g., require a runtime to be usable) or other reason that is "inherent" to Rust?
We discussed a lot of these last May in person. Haven't kept track of who's doing what on these fronts.
> have there been any interesting pondered/proposed avenues for speedup that were rejected because they would result in too much breakage, violate a core tenant of Rust (e.g., require a runtime to be usable) or other reason that is "inherent" to Rust?
Yes, but I haven't been part of all of them and can't ellaborate much here. Opening a thread in internals.rust-lang.org with that question might get some good info sooner that I could.
Partly; OCaml does not, in the general case, generate code for a function for each boxed data type it is called with, for example.
This, and the fact that the compiler does not optimize extensively, makes for fast compilation.
The code still runs fast, especially for a language with gc.
* Windows support is mediocre due to decades of not supporting it at all.
* OPAM is a nightmare. Surprisingly buggy and extremely confusing. We're not talking Pip levels of badness but it's nowhere near as good as Rust, Zig or Go's equivalents.
* A silly obsession with linked lists. Ok I understand why but it's still annoying.
* Ocamlfmt thinks it is writing an essay, and generally makes things less readable IMO.
* The syntax is not easy to read. They threw away all the useful punctuation that help you visually parse code.
* Tiny community.
* Very spartan documentation. Examples are very rare.
* Global type inference is definitely worse than Rust's local approach because it makes errors much worse, and makes the code harder to understand.
* Native int type is 63 bits.
I haven't even done much OCaml but it's definitely got enough issues that I strongly prefer Rust. Just the community size is reason enough really.
That said, it's still way better than Python, Ruby, PHP, Java, JavaScript and Perl. Those are kind of the Z-tier languages though so I guess that's not saying much.
If it was a choice between OCaml and Go, Swift, C#, Dart... then it wouldn't be a slam dunk either way. Unless you wanted Windows support and then OCaml is a crazy choice.
I used OCaml extensively for a few years, around the time of OCaml 3 and OCaml 4, and I can add a few cents to this discussion.
Some of the points listed here can be considered a matter of taste or opinion, some are indeed pain points, and some are implementation details.
OCaml as a whole is hard to directly compare with most other languages you mentioned above as "better" or "worse". It both suffers and benefits from being an academic/research project not directly in control of a larger corporation.
As a language, IMHO, it is miles ahead of mostly all the languages mentioned above. It recently adopted a novel mechanism for modeling concurrency called algebraic effects, together with state-of-art multi-core support. This not only abstracts away several features that are usually hardcoded on most languages but puts it on another level as a language and abstraction capability. There are other toy languages that implement similar mechanisms or part of this, but none with the adoption level of OCaml.
However, since it does not have the same amount of resources and adoption, progress sometimes is slower that one would expect. Documentation can be sparse, community is smaller, etc.
Regarding OCaml on Windows, I myself used it exactly 20 years ago. It not only has one implementation, but three. There are some tradeoffs and support is not at the same level as Linux but it's still there, and I wouldn't call it mediocre:
You might find it harder to find libraries, for sure. I have not checked the situation recently, though given the smaller community that is likely still the case.
As a tongue-in-cheek comment, I could definitely say "OCaml is certainly not a good language - not as bad as most of all the others though".
> We actually had a recent Cloudflare outage caused by a crash on unwrap() function
> 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?
Probably if you use a lot of Arc<Mutex<Box<T>>> languages with proper runtime (like Go or Java) are gonna be more performant, in the end they are built with those abstractions in mind. So the question isn’t only how much the nature of the problem it is, but also how common the problem is, and is rust a correct way to solve this problem.
If you use a lot of Arc<Mutex<Box<T>>> you you probably just learn to use Rust properly and just use Arc<Mutex<T>> instead because it pretty much never makes sense to have a Box inside an Arc...
I say that as someone that thinks Rust's learning curve is the main reason it rarely makes economic sense to use it.
This is either performance art or rage bait. The opinions here are so wild. There are so many claims here that are wrong and just strange, it is hard to know where to start.
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++.
There is always a trade-off. You really cannot provide enough information for the compiler without the current signatures. There is a certain point where you cannot compress the information without losing some features.
> telling a victim “but the memory was not corrupted in the crash” is a weak consolation. We actually had a recent Cloudflare outage caused by a crash on unwrap() function. It’s probably the strongest point of my whining: Rust is memory safe and unreliable. The price of memory safety was reliability
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.
First, he didn't call the "crash()" function, he called the "unwrap()" function. The fact that they decided to call the crash function "unwrap()" is not the OP's fault, it's the language authors' fault.
Second, you totally missed the OP's point about reliability. If one has to choose between UB and an immediate halt, those are pretty sucky options. And the OP is 100% right about Rust crashing all the time. Nothing insulting about that, just a fact.
You get to choose between UB, a crash, or handling the error — same as most other languages.
It’s not a reliability issue of the language if as an author of software you choose to crash in your failure handling cases. Claiming otherwise is either disingenuous or a failure to understand what actually happened.
No, it's not the "same as most other languages". C and C++ are actually the only mainstream languages that suffer from UB to this extent.
The fact that, in practice, with Rust you get a crash instead of UB is 100% a reliability issue with the language. The crashes are inbuilt. And blaming the crash on the author, saying they "chose to crash", is exactly the same as blaming UB on the author of C code, saying they "chose to double-free".
> The fact that, in practice, with Rust you get a crash instead of UB is 100% a reliability issue with the language. The crashes are inbuilt.
This is totally false. It's not in the least hard to avoid crashing.
match some_result {
Ok(value) => { // handle the value },
Err(e) => { // handle the error condition }
}
The fact that Cloudflare chose to handle a result with the "panic if this result is an error" function is 100% on them, not on the language. Blaming the language is like claiming that any language which has assert is a problem because the assert can crash your program. Yes, that's what it's there for, so don't use it if that isn't what you want.
And don't give me the "the method name isn't obvious enough" argument you used elsewhere. That holds no water. It's basic Rust knowledge to know that "unwrap" will panic if the value is an error (or None if it's optional). If the engineers writing the code didn't know that, then the problem is they didn't bother to learn how their tools work, which again is not the language's fault.
What UB? This has nothing to do with UB; it'd be well-defined in any language. It's equivalent to this python snippet:
config = load_config()
if !config.valid():
sys.exit(1) # config is corrupt. restart pod
Did Python do something wrong by letting users call `sys.exit`? No. This is a deliberate crash. Under other circumstances, crashing might have been a valid strategy, but here it turned out to be a bad choice, since Cloudflare's infrastructure was restarting the service with the same bad config every time.
Sys exit does not crash. It raises a SystemExit exception, which can be caught on any layer above it. Given that python uses exceptions for trivial things like loop termination this can be considered normal flow control.
Yeah, and in Rust you can catch the panic from `unwrap()` with panic::catch_unwind. You just don't, for the same reason you don't catch SystemExits. If a SystemExit is being thrown, it's because you want to crash; if you don't wan to crash, don't throw a SystemExit.
If I could choose between UB and a crash I will chose the crash every time. The sooner the better, preferably in test. And that's where CF's real failure was.
Idk, it's a general rule of thumb that the more mutable shared state an algorithm has, the worse it scales. So if you're trying to scale something to be concurrent, mutable shared state is an antipattern.
At scale, algorithms are commonly limited by memory bandwidth, not concurrency. Most code can be engineered with enough cheap concurrency to efficiently saturate memory bandwidth.
This explains why massively parallel HPC codes are mostly minimal mutable state designs despite seemingly poor theoretical properties for parallelism. Real world performance and scalability is dictated by minimization of memory copies and maximization of cache disjointness.
as noted someone else, it is lock contention that doesn't scale, not mutable shared state. lock-free data structures, patterns like RCU ... in many cases these will scale entirely appropriately to the case at hand. A lot of situations that require high-scale mutable shared state have an inherent asymmetry to the data usage (e.g. one consumer, many writers; many consumers; one writer) that nearly always allow a better pattern than "wrap it in a mutex".
Mutable shared state is literally the nature of contention. It's true that locking is the mediocre default, but "avoid locks" is not a silver bullet. Alternatives have their own tradeoffs. If you "carefully design" a solution, it's probably because you're not just using an alternative but actually taking care to optimize, and because you have a specific use case (which you described).
It's lock contention that slows things down more than anything.
But it's really an 'it depends' situation.
The fastest algorithms will smartly divide up the shared data being operated on in a way that avoids contention. For example, if working on a matrix, then dividing that matrix into tiles that are concurrently processed.
> It's lock contention that slows things down more than anything.
It's all flavors of the same thing. Lock contention is slow because sharing mutable state between cores is slow. It's all ~MOESI.
> The fastest algorithms will smartly divide up the shared data being operated on in a way that avoids contention. For example, if working on a matrix, then dividing that matrix into tiles that are concurrently processed.
Yes. Aka shared nothing, or read-only shared state.
> T, T&, T*, std::optional, std::unique_ptr to describe similar things, each broken in its own way
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.
> No matter what language you use, most of the code running between what you wrote and the hardware will be written in C.
The goal of changing that is a big part of why there’s so much discussion about Rust.
> Your choice for the 1% on top is not very consequential. There is still a huge attack surface area no matter what.
For an internet-exposed service, the 1% that implements that service is important. Most of the rest of that attack surface is only accessible if an attacker gets past that first layer.
Spending out something better isn’t easy. As an applications developer I want to ask “Why don’t you just use Java/C#?” and I’d go so far to say that the software reuse revolution behind Java was not OO or it’s particular approach to OO but rather the garbage collector.
That is, building applications out of premade parts is a struggle in C or C++ or rust because memory management is part of the API. C devs would be very concerned about having control of memory allocation and would like to have the choice of reusing a buffer from the application in the library or have the library allocate into an arena managed by the application, etc. It’s complicated enough that libraries can’t reasonably support every scenario application developers would like and ultimately tough because to free something the application has to know if the library is done with it or the library has to know if the application is done with it…. However, the garbage collector knows!. In the end there are a lot of libraries you can’t really write for C or if you can write them you have to write them assuming the application allocates or a certain way or you lose the benefit of being in control of allocation that C allegedly gives you.
On the flip side I think C is too high level in some cases, for instance you come to think the gymnastics involved in written embedded C or device drivers are normal but there are quite a few things that are a little bit cleaner in assembly language and I write things for AVR-8 that are rather small but it drives me nuts that C is moving the stack pointer around and following calling conventions that are not at all necessary for these particular programs.
I had friends who worked in the IBM Mainframe world where it is still common for applications to have bits written in assembly because of efficiency or to get finer control than you can get with COBOL. Part of the COBOL puzzle is that you have to be a Macro Assembler programmer to work on that stuff and you can’t just port it to GNU COBOL on Linux without also porting the assembly!
We’re still living in a multi-architecture world so the interesting idea of trying to make it easier to write assembly (imagine a super macro assembler with an integrated theorem prover) is a non-starter. Let x86 founder for a decade and if RISC-V makes no progress that picture could be different in a few years.
over the past decade i've spent alot of time compiling rust code for arm6 / arm7 cpu's, which is a fancy way of saying that in my free time i have spent alot of time running `cargo build` on a variety of raspberry pi's.
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
What a waste of time article. There is plenty of debunking of the points already so I won't repeat them.
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".
> 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.
There is a fundamental trade off between (1) Memory Safety (2) Zero cost abstraction/Performance (3) Ease of use
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.
"they only corrupt user data and act sporadically"
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.
You cannot go along like “I’m writing a cold path high-level code, I don’t need performance, I don’t need to go deeper into lifetime handling, I just want to write a high level logic”. You will be forced into the low level nuances every time you write a single line of Rust. There is no garbage collector for Rust and will never be — you will have to semi-manually pack all your data into a tree of ownership. You have to be fluent in ownership, borrowing, traits to write just a few lines of code.
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.
Zig... is surprisngly used a lot given how rough the state of the language is. It makes me think that if it ever reaches v1.0, it has a very good chance of being at least a "Kotlin", probably a "elixir"/"haskell", and a decent enough shot of "typescript".
I think people are missing the main point. The real issue with Rust is that it is a designed language which is really tuned and optimized for a specific use case. And for that specific usage, it is really, really good. But even so, it requires a lot more up-front work, due to the limitations and restrictions it imposes.
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.
Node.js and Go are both memory safe, as are Python, Ruby, and Java. "Memory safe" is a term of art referring to susceptibility to memory corruption vulnerabilities in code written by an ordinary practitioner of the language. Almost invariably, attempts to show languages like Go and Python as memory-unsafe involve a programmer deliberately working to defeat the language. But you can do that in any language, including Rust.
There are essentially just two mainstream memory-unsafe languages: C and C++.
I agree, and I personally wouldn't call golang memory safe for that reason. Thomas's semi-definition includes the word "vulnerability", which narrows the scope so much that golang fits under the bar, since the common data race that causes memory corruption hasn't been shown to be exploitable without being contrived.
My personal definition of memory safety for a language like golang would specify that you can't cause this sort of memory corruption without an explicit call to unsafe, but there's no real definition to fall back on.
The same thing happens any time a message board confronts a professional term of art. The same thing happened with "zero trust", where you'd have long wooly debates about what was meant by "trust", but really the term just meant not having a conventional perimeter network architecture. Sorry, but the term as used in industry, by the ISRG, and in government guidance refers specifically to vulnerabilities.
"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.
The amount of Rust code using unsafe is a major issues for a language build around safety. And yes, the same argument can also be made about Go having a unsafe keyword.
The fact that there exist crates to detected the usage of unsafe in dependencies, shows that its a rather liberal used keyword. Geiger comes to mind.
Unsafe in a language like Go is very rare, mostly because people do not program at such low system level to get the max performance out of it.
Rust code with unsafe: 1.7M
Go code with unsafe: 400k
and for comparison, Go has about 2.3x the amount of repo's. So Rust has about a 10x more usage of the unsafe keyword.
While unsafe is always a risk in Rust, measuring the risk is not nearly as straightforward as counting lines of code. In particular, Rust focuses on encapsulating unsafe code behind safe wrappers that prevent misuse, so the better measure is determining which crates don't do this, and to what extent they can be easily patched to do so.
> "there is just no perfect correctness possible in the Turing machine model"
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.
Theorem prover ideas have an impact on Java, Rust and a lot of languages —- it really would be great to see something that accomplishes even more…. Would be nice if you could have a program that lives side by side with a correctness proof.
> Unfortunately, it’s impossible to make Rust compile fast. The problem is inherent to all similar generics-heavy languages, like Haskell.
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.
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.
> 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 — that’s why I’m telling the language designers went overboard.
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.
I'm annoyed that this submission's title was changed. This was first submitted with the original title, "Rust is a disappointment," and got flagged. It looks like it's been unflagged and the title has been changed.
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?
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).
My understanding is Rust compiles each crate in the same way C++ compiles each .cpp file, so if you stick everything in a single crate you get horrible compile times.
This does seem like a poor design decision by Rust to me, forcing people to break things into arbitrary crates just to get reasonable compile times.
It also seems like a disaster for incremental compilation.
> This does seem like a poor design decision by Rust to me, forcing people to break things into arbitrary crates just to get reasonable compile times.
Not necessarily, since codegen units can introduce intra-crate parallelism during compilation.
But in any case, as with basically everything there are tradeoffs involved in choosing compilation unit size. Making your compilation unit crate-sized also means that you have some more flexibility in your code organization (e.g., stuff can mutually depend on each other, which is itself potentially useful and/or harmful) and you don't run into other potential issues like the orphan rule. There are also potential impacts on optimization, though LTO muddy the picture. Codegen units are just the cherry on top.
There's almost certainly other things I'm forgetting and/or not knowledgeable about as well.
Unless I need close to 100% memory safety with no compromise in performance I'd rather write Zig, Odin or Go.
Zig and Odin are much more enjoyable to write and provide enough safety for a lot of applications, and Go gets you 90% of the performance of Rust without the complexity.
I swear there are people who take a massive amount of pride in using languages or technology that are obscure. That thing use to be Rust, but now that it's become fairly mainstream they have to find something new to move to.
I wonder how long it will be before we start seeing "Ada is the new Rust" YouTube videos.
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?
I think we’ve officially reached the inflection point where the Rust haters have become more annoying than the Rust evangelists. Maybe in a couple years we will finally be able to stop writing blog post about it.
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 — this fact alone makes Rust a viable tool, just because you can pick it from the shelf and employ as-is. This blog was generated with Zola, written in Rust — I did not have to write a single line of Rust code to use it. And the Rust is a good fit for Zola SSG because of its non-interactive nature with one-way flow of immutable data. Just, please, don’t run around screaming “we should all switch our development to Rust because it’s the best programming language”.”
Man, I explained it in the first sentence of the article — it's not bad, it's much worse than it could have been. The main body of the article is not hate — it's plain facts. Everybody working on a significant Rust codebase agrees that Rust compilation takes eternity. Complexity? I know people that like complexity, they would say "that's a great language because of how hard it is to write a program in it!" — complexity would feel like a praise for them. Shared state? "Just don't use it, you are doing it wrong". That's is, where is the hatred?
> The main body of the article is not hate — it's plain facts. Everybody working on a significant Rust codebase agrees ...
Lol. Its not facts. Its a description of frustrating things you've experienced working with rust, dressed up as "deep truths about the language". You don't speak for the rust community. This article would be much more interesting if you just talked about your own experience without pretending your issues are universal.
Re: compilation time, in the 2024 state of rust survey 25% of rust developers said slow builds was a big problem. And thats a lot of people! But 19% of people said its not a problem at all for them. Its certainly not "everyone".
I suspect if you keep using rust, the things that annoy you about the language will change a lot over time. Some things will stop bothering you, and some things will start bothering you a lot more! (Like IMO Rc/Box/etc isn't a big deal. Once you learn to structure your code in a rusty way, you almost never need that stuff.)
I really like rust now. But I found learning rust to be incredibly painful. I get why you're struggling with it. But please don't confuse your struggle for universal truths about rust. You're only one person.
Speaking of, maybe I started paying attention at the wrong time, but I could swear I've seen like 10x more post/comment volume whining about how annoying the "Rust evangelism strike force" supposedly is than actual excessive Rust evangelism
Can you give some examples? C/C++ devs seem to be very upset about rust content. Where all these annoying articles claiming we should rewrite everything in rust? They must be all over the place given how much C/C++ devs are upset. But I don't think I've read any?
There was that article from the android team about how rust improved their development workflow[1]. Is that what you're talking about? Was that article emotionally upsetting? Do you wish it wasn't written? What in particular is upsetting? Do you want people to stop writing technical articles to protect your feelings?
I haven’t seen a positive Rust article hit HN in over a year. Seems the zeitgeist has turned against it. All it took was the US government giving the thumbs up I guess.
On the other hand, lets face it: most of the time security in IT systems is the least priority. I mean after shipping fast, iterate fast, better performance, compatibility, architecture soundness (whatever it is), convenient tests, docs with UML diagram, well-designed interface — and somewhere in a distant drawer on the bottom you may find a note about security issues. It's often times people talk about importance of security after it destroyed the whole business.
We need more of the security. We probably don't need the Rust though.
security incident destroying a business is so rare and penalties for security breaches are non-existent and hence while everyone talks “security is important” it really isn’t all that important - in vast majority of the situations. I mean, fucking experian, the company whose sole purpose for existence is collecting and keeping data on everyone safe leaked everyone’s data and everyone was like “oh ok, thats cool, carry on…”
Uhm, I would have picked Rust just for shipping fast, iterating fast, better performance and compatibility. The security is a bonus that comes along for the ride. You probably haven't had the displeasure to work with C++ in combination with ROS. That experience really soured me on C++.
We really just need official/honest guidance on Rust for what works and what doesn't. The classic example is the dodging around cyclic datastructures.
Tl;DR Rust doesn't support any form of cyclic datastructure without indirection or unsafe. The indirection tooling is weak, and most real examples simply switch to unsafe rust. Unsafe rust is completely fine if you know what you are doing with memory, and is ok to use in these situations.
There are a few other gotchas that we just need to be clear about, some of these gotchas are limiting for developing higher level software and some are not e.g. String handling. If you are comfortable with unsafe, the rust toolchain is vastly superior to C/C++ development making it as close to an ideal replacement as we are likely to get.
A couple years ago I implemented a btree (technically order statistic tree) in a couple thousand lines of unsafe rust for a project. I wrote it more or less how I'd do it in C. Each internal node and leaf node was a separate heap allocation and internal nodes had an array of child pointers. It was surprisingly hard to program up. And complicated!
In my opinion, unsafe rust code is worse to use than C because rust is missing the arrow operator. And rust still requires strict aliasing to be followed even in unsafe code. This makes complex unsafe code very hard to implement correctly. Like, it’s easy for something to look right and work correctly but for MIR to still find subtle issues.
Eventually I rewrote my btree on top of Vecs. My node & leaf pointers are now array indices. The result? There is no longer any unsafe code. The code has become significantly simpler and it now runs ~10% faster than it did before, which is shocking to me. I guess bounds checks are cheaper than memory fragmentation on modern computers.
I have so many thoughts having done that. First, I think this is actually the right way to write rust. Yes, manually keeping track of which array slots are in use is inconvenient. But unsafe & pointers are also quite inconvenient in rust. Programming like this makes use after free bugs possible to write. But it’s still memory safe by rust’s definition. It’s impossible to get arbitrary heap corruption because there are no raw pointers. And the indexes are bounds checked.
I also don’t think the resulting code is any worse than the equivalent C++. Everyone talks about memory safety but IMO rust’s best features are enums, traits, cargo, match expressions and so on. Even when you do a run around the borrow checker, it’s these features which make me keep coming back to rust.
I agree better guidance would be nice, but so many words have been spilled on rust already. Would you find content talking about subtle stuff like this? Sometimes the only way to learn is by trying stuff out.
>Eventually I rewrote my btree on top of Vecs. My node & leaf pointers are now array indices. The result? There is no longer any unsafe code. The code has become significantly simpler and it now runs ~10% faster than it did before, which is shocking to me. I guess bounds checks are cheaper than memory fragmentation on modern computers.
Optimizations are very complex and potentially fragile in Rust, LLVM has to sort through tons of generated IR, so it might be just that native Rust structures are optimized better for compilation. Particulary, Rust is able to optimize out some bound checks.
Do note that binary trees are mostly an obsolete legacy today — they are way too cache-unfriendly. I mean you could have written similar code in C++ using std::vector or std::dequeue and get the bounds checking too.
>Everyone talks about memory safety but IMO rust’s best features are enums, traits, cargo, match expressions and so on
C++20 with concepts mostly reproduce the traits. C++17 with std::variants emulate enum/tagged union. Match is unmatched by C++, that's true.
Cargo is good for as long as there are few packages in there. Large projects already suffer from five versions of serde in one build and dependencies on FFI-connected libs that cargo itself cannot build. I mean look at the NPM nightmare — and they've mostly dodged FFI-s.
> Do note that binary trees are mostly an obsolete legacy today — they are way too cache-unfriendly. I mean you could have written similar code in C++ using std::vector or std::dequeue and get the bounds checking too.
As a sibling comment said, its a b-tree not a binary tree. B-trees are - as far as I know - the fastest data structure on modern computers for the class of problems they solve.
And yes, I think if I ever go back to C/C++ I'll try this approach out. It might also work great in GC languages like JS/TS/C#/Go because there's fewer pointers to keep track of.
> Cargo is good for as long as there are few packages in there. Large projects already suffer from five versions of serde in one build and dependencies on FFI-connected libs that cargo itself cannot build. I mean look at the NPM nightmare — and they've mostly dodged FFI-s.
I haven't run into the "five versions of serde" problem, but I can easily imagine it. I've lived NPM nightmares more times than I can count. But I'd still prefer that to all the problems you get from CMake, autotools and Makefiles. At this rate we're going to get self driving cars before we have a single sane build system for C.
> Particulary, Rust is able to optimize out some bound checks.
It doesn’t optimise out the bounds checks. I checked the assembly.
Bounds checks in rust always look so ugly if you look at the assembly output because there’s all this panic string building and whatnot. But in practice, I think it’s just that modern CPUs have excellent branch prediction. A branch that follows the same path 100% of the time is cheap. Especially when it has UNLIKELY() annotation hints in the code. This is the case for bounds checks. They just don’t really show up in benchmarks as much you’d think.
> Do note that binary trees are mostly an obsolete legacy today — they are way too cache-unfriendly
BTree is not Binary Tree. It's B-Tree and is cache-friendly
> C++20 with concepts mostly reproduce the traits.
C++20 concepts are not the same as traits. Concepts are structural and awkward to use compared to Traits which are nominal. There are other important differences, too.
>Do note that binary trees are mostly an obsolete legacy today — they are way too cache-unfriendly. I mean you could have written similar code in C++ using std::vector or std::dequeue and get the bounds checking too.
This is simply not true, it's an ongoing thorn of mine that the Rust community seems to decide that anything which cannot be programmed in rust is obsolete legacy. This is a silly stance which is harming adoption.
I for one have coded dozens or even hundreds of tree structures. My most recent tree was a hierarchical context management system for an LLM agent!
> it's an ongoing thorn of mine that the Rust community seems to decide that anything which cannot be programmed in rust is obsolete legacy.
Nobody is arguing that you can't program a binary tree or b-tree in rust.
I think its true that binary trees almost always perform worse than b-trees in programming in general. But that isn't a comment about rust. Its a comment about modern CPU memory & cache behavior.
Zig currently sits in the hype cycle like Rust/Ruby/Lisp/etc once did here. Eventually something will come along and Zig will be in the hate cycle.
In reality none of these things need the religious wars that seem to go back and forth. It's just an incredibly unfortunate and annoying aspect of how programmer-centric communities tend to go.
The objective rate of improvement in programming languages has been slower than virtually every other field. Computers have gotten millions of times faster since the advent of C, but programming languages have arguably gotten maybe 10% better in that span.
>ORMs, OOP, Git, JavaScript bloat, Linux vs Windows
ORM and OOP whine is niche, agreed. Linux vs Windows is irrelevant because windows runs linux nowadays — I don't think I've read a single article about it.
Git? Okay, mostly circumvented by solutions that don't carry any implementation from the original Git, but have "git" in the product name.
Javascript bloat? I'm pretty sure that's still a hot topic. I don't remember it being solved, do you? Like if I open website and it greets me with a window suggesting to apply cookie policies for 300 (three hundred) trackers on the website — isn't it worth talking about?
>Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times.
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.
Although naively factored builds can be slow on rust, I firmly believe that most folks complaining about this problem have not taken the time to learn how to do this and their builds could be perhaps 10x faster. Bringing this up an important counter-point that all too frequently is ignored or met with hostility, as this replier has done.
I do not understand how you justify your claims. Should I link any number of instances where Rust team members admit to compile times being a major issue, one which prompts significant effort to improve? Perhaps you are right about 10x speedups, but then that clearly isn't enough, reading the room.
I also do not understand how you see hostility in my comment. For one thing, I did not downvote you. Rather, your original comment is dismissive, even if the article it replies to is dubious. For another, it would also be trivial to see that I am both highly supportive and informed about Rust. Your comments simply do not help, certainly not with the common perception of Rust fans as zealots.
Don’t know what to tell you. Just trying to keep things real in response to a highly ungrounded post. The issues with compilation times are as severe an issue because of the reason I mentioned — folks don’t like to think about how they factor their build. So some members of the core team are sympathetic to that — and for good reason.
But the virtues of shifting context to the build and refactoring it is rarely discussed and would alleviate many individuals problems. I see it rarely mentioned, just “rust is slow to compile” so I really do feel it should be discussed more; even if I could have perhaps mentioned it in a way you (and others?) would have experienced as less dismissive.
I can't speak for everyone, or even the majority, but I know that oftentimes large projects focus on build times, undergoing refactorings as you describe, and their compile times are still high. To make up some numbers, maybe the fraction of projects that have unacceptable compile times could be reduced from 80% to 40% (at what effort?), but that 40% remainder probably includes many large, popular crates.
Because it follows same structure as the one used by LLM-s. At least there is a reason to think so — before you've tried to actually read the article and realize LLM-s just don't write text like this... yet. Of course, this structure is also the one used by scientific articles, which I read a lot too, so I'm really inclined to follow this style. "Has the form of scientific article but statements are not precise = AI slop" — that's the implication.
Funny fact: one of the reasons Qwen suggested my article is LLM-generated is because it considered link as impossible. I was so gaslit I opened the article and clicked the link. And it worked. Mic drop.
The ragebait part is because it feels more provocative than sincere.
Some examples from the introduction:
> Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times.
I've done significant C++ and Rust and Rust compiles WAY faster than C++ for day-to-day incremental compilation. C++ suffers from the header inclusion problem and modules may as well not exist because you can't practically use them.
> Arc<Mutex<Box<T>>>
This is intentionally over complicated, there is no reason for the Box to be there.
> You cannot get 99.999% reliability with Rust — it crashes all the time.
>I've done significant C++ and Rust and Rust compiles WAY faster than C++ for day-to-day incremental compilation. C++ suffers from the header inclusion problem and modules may as well not exist because you can't practically use them.
It really depends on what you are compiling. I did lots of C/C++ that compiled 50k lines of code in 10 seconds FROM SCRATCH — I doubt you can do it in Rust. To be fair, headers in that project were somewhat optimized for compilation speed (not "hardcore", but "somewhat"). People forgot how fast C/C++ compilation can be without 10 Boost includes in each module.
>This is intentionally over complicated, there is no reason for the Box to be there.
Arc<RwLock<Option<T>>> — sounds good now? Don't get me wrong — C++ can be just as horrible, but Rust made it a rule, you can only write your program like this.
>What does this even mean?
I've already answered above, but I can repeat: there are runtime models that allow crash and recover, there are models that crash and limp. In Rust there is only one model of crash: you just crash.
You absolutely can. You'll need to pay attention to how things are structured and not all codebases will be equally amenable to such techniques, but those are shared characteristics with C++.
As you said, "It really depends on what you are compiling."
> In Rust there is only one model of crash: you just crash.
> It really depends on what you are compiling. I did lots of C/C++ that compiled 50k lines of code in 10 seconds FROM SCRATCH — I doubt you can do it in Rust. To be fair, headers in that project were somewhat optimized for compilation speed (not "hardcore", but "somewhat"). People forgot how fast C/C++ compilation can be without 10 Boost includes in each module.
Incremental compiles in Rust are very fast because it has an actual module system instead of textual include. I don't care much how long from scratch compiles take, but even there my experience is Rust is faster than C++.
> Arc<RwLock<Option<T>>> — sounds good now? Don't get me wrong — C++ can be just as horrible, but Rust made it a rule, you can only write your program like this.
I'm not sure what non-garbage collected language would be better here. C++ would be about the same. C would be far far worse as it has no templates. Garbage collection would allow you to omit the Arc, and a language like Java where nearly _everything_ is optional would allow you to omit the Option, but I don't think many people would make this trade.
> I've already answered above, but I can repeat: there are runtime models that allow crash and recover, there are models that crash and limp. In Rust there is only one model of crash: you just crash.
You haven't defined what "crash" means. Rust uses a Result types for error flow and you have just as much control over recovery as any other language. If you are talking about panic, well yeah, that's like calling abort() in C, except it allows more fine grained error recovery with catch_unwind instead of a global SIGABRT handler or w/e for your OS.
Yeah, the article was written in Markdown, LLM-s employ markdown formatting too. It's not a typical length of LLM response — it's approx 1.5-2.0 times longer than a typical long LLM response. Not easily noticable to a human being though, indeed.
I disagreed with your article, but this critique of it is just goofy. I also write in Markdown, use lists where appropriate, and — gasp! — write em dashes where appropriate.
You think an AI wrote "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 — this fact alone makes Rust a viable tool"? No it didn't.
It's 200% LLM used in production — like 10 hours of dialogs right before writing the article. I had much more hours of coversations with Rust fanboys and it was mostly a waste of time, they just would not try to negotiate on Rust's weak points. I would definitely not be able to write the article with only human support — it's really sad to conclude that LLM-s are much better assistants because they are neutral and objective.
Why would I do this and why do you think I did? Or do you feel like my english is so bad I'm probably writing ransom note out of pieces of LLM output? I can ensure you I'm good enough at typing and talking in english to not require copy-pasting. Do you have any quotes from the article that you feel like were copy-pasted from LLM?
> 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.
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.
>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.
I have a working theory that the classic programming is basically dying out:
https://bykozy.me/blog/llm-s-are-not-smart-rather-programmin...
You just cannot write fast and reliable program neither with C++ nor with Rust, because the fundamental model is broken and nobody's really bothered fixing it.
Python? Jesus. One of the worst languages. Half of the community doesn't use static types, `import` is hilariously bonkers. Until very recently (uv) the tooling was absolutely atrocious (they still haven't fixed that dependency confusion issue). Insanely slow.
> I would love to hear what he thinks a good programming language is
Also, not the OP, but I bet it is Python.
- No compile time.
- Not as complex as C++.
- Memory Safety, while they don't care about this apparently, but nice to have.
- Plenty of ergonomic GUI style programming, like PySide (Qt for python).
Of course, I know there are many downsides to python. Such as interpreted languages, especially ones that are duck typed are very slow to run... but that's not one of the OP's complaints.
The article complained that a Rust program can crash when you call `unwrap`—in fact, the author says that's their strongest critique. Python crashes when you call `sys.exit`, so it's no better.
Unfortunately I don't think their critique is really coherent—this is an absurd standard.
Other languages have some kind of exception mechanism so the crashing unwrap gets caught and handled, preferably sanely. Erlang in fact is written around the idea of expecting stuff to crash, and restarting the crashed thing when it happens.
This crash gets caught and handled too: the process exits, the kubernetes pod fails, and the deployment recreates it from scratch. Panicking like this is a request for the infrastructure to turn the whole service off and on again, which is sometimes the correct way to deal with transient failures. The problem here is that the infrastructure was restarting the service with the same bad config every time, causing a crashloop. It's a system design bug.
I have never once seen someone try to catch a NoneType error in Python or an abort()/assert() in C, at least outside of things like HTTP handlers that try to catch everything - which you can also do in Rust!
> In fact, for many applications malfunctioning is better than crashing — particulary in the embedded world where Rust wants to be present.
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.
Something else I usually don't see: A system hitting a fail-safe is a lot easier to detect and handle from the outside than one that just enters an unknown invalid state.
Like, if the rule were "Always-Keep-Running" then hospital equipment power supplies wouldn't have circuit breakers that cut the power when something is wrong. But cutting power seems lot easier to detect for the backup power supply so it can fully take over.
Engineer:
“It crashed on an assert…”
Pointy haired boss:
“… well, what are you waiting for!? remove all the asserts so it doesn’t crash any more!”
it's funny because I have seen the opposite. Engineer: "it crashed because it dereferenced a null pointer" boss: "add null pointer checks everywhere!"
... and because it used "if" instead of "assert", it made the null pointer arg a valid argument, making it a tolerable state of the running software, which displaced the locus of crashes far from the source of the issue. Moral of the story, use "assert" to make it crash as early as possible and debug THAT. You want to restrict the representable states in the software, not expand them by adding null checks everywhere.
Yeah, the blog post is a very confused write-up. I saw lots of similar posts on LinkedIn recently, with quite a lot of likes and echo chamber comments. It’s just hilarious how a narrative emerges that reinforces biases due to ignorance. There must be a name for that sort of fallacy.
I love to write in Rust precisely because I can express failures more explicitly, it’s the transparency that wins here.
I’d frame the issue Cloudflare had rather in the PR review and QA corner, maybe as some AI complacency. But it’s not a problem with Rust.
> There must be a name for that sort of fallacy.
Motivated reasoning
I love the ub Go forces you to have explicit error handling ones the most.
Also stopping is a state which definitely might happen anyway and must be planned for. The pacemaker's wires can be dislodged or damaged, power sources fail, these things will stop the pacemaker regardless of how much you love the "just keep going" approach to software engineering. Which means medics have already thought about what they're going to do when this happens to a patient, and "The software failed" just goes on the same list as "10 year battery only last 8 years" in terms of undesirable but hardly impossible scenarios which constitute a medical emergency.
> 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.
Strong agree on this one, usually embedded systems are designed to "fail safe" on crash - the watchdog will trip, and hardware reset will put everything in a deterministic, known safe state.
What you want, above all else, is not to fall into undefined behavior. That's the beauty of `unsafe`, it bounds UB into small boxes you know to test the hell out of.
It's honestly mind boggling how people react to this. Rust turns unknown failures in C and C++ into known failures and suddenly the C/C++ people start caring about the failures, but attribute the failure to the new language, even though the same failures are secretly lurking in their C/C++ code bases. It's kind of like trying to silence a whistleblower.
>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.
I am running into an undiagnosable CUDA "illegal memory access" problem in vLLM, a code base that is a mix of python and CUDA (via pytorch). At a certain load something appears to either overflow or corrupt the memory and vLLM restarts, which takes a minute, because it has to reload several dozens of GBs into memory and then rerun the CUDA graph optimizations.
The pacemaker argument is complete nonsense, because the pacemaker must keep working even if it crashes. You can forcibly induce crashes into the pacemaker during testing and engineer it to restart fast enough that it hits its timing deadline anyway. Meanwhile a silent memory corruption could cause the pacemaker to enter an unknown state where the code that runs the pacemaker algorithm is overwritten and it simply stops working altogether. Having a known failure state is a thousand times more preferrable to an unknown number of unknown failure states. Critical sections (mutexes) and unsafe code has to be panic free (or at least panic safe) in Rust, so the concept of writing code without panics isn't exactly a niche concept in Rust. For every panic based feature, there is usually a panic free equivalent.
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.
>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.
Some very solid argument here. However, as already implied in my article, you can get most of the guarantees without losing your sanity. Memory-safety-related problems are important, but they are not the sole source of bugs in applications — as developers of Zed found out.
>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.
It might be counterintuitive, but garbage collectors in multithreaded code can be very efficient. I mean you just spawn lots of objects with random references in between and then eventually GC untangles the mess — it's zero overhead until the GC cycle. Escape analysis and semantic-reach containers can reduce GC work a lot (so you don't have the classical JVM GC problems). More specialized things like RCU and general quescence-state reclamation can be totally pause-less.
> Some very solid argument here. However, as already implied in my article, you can get most of the guarantees without losing your sanity.
I think this is part of why your article is causing a strong reaction from a lot of people; quite a lot of the justification for your point of view is left implied, and the concrete examples you do give about Rust (e.g. `Arc<Mutex<Box<T>>>>` and `.unwrap`) are hard not to see as straw men when plenty of people write Rust all the time without needing to rely on those; it turns out it's also possible to get more reliability out of Rust for those people without losing their sanity.
Most of the opinions you give are hard to distinguish from you personally not finding Rust to provide a great experience, which is totally valid, but not really indicative of "core problems" in the language. If you instead were making the argument of why you don't personally want to write any code in Rust, I don't think I'd have much criticism for your point of view (even though I wouldn't find much of it to apply to me). Then again, the article starts off with a statement of previously having made an intentionally provocative statement purely to try to compensate for a perceived bias in others, so maybe I'm just falling for the same bit by trying to engage the article as if it's serious.
Also the argument with `Arc<Mutex<Box<T>>>>` boils down to "Rust makes it hard to work with automatic reference-counted shared mutable heap-allocated state." In which case... mission accomplished? Rust just made explicit all the problems that you still have to deal with in any other language, except dealing correctly with all that complexity is such a pain that you will do anything you can to avoid it.
Again, mission f#*@ing accomplished. Maybe you DON'T need that state to be shared, reference-counted, or heap allocated. Maybe you can refactor your code to get rid of those annoyingly hard to deal with abstractions. And you end up with better, more reliable, likely faster code at the end of it.
So many times I've tried to do something in Rust the old fashioned way, the way I have always done things, and been stopped by the compiler. I then investigate why the compiler/language is being so anal about this trivial thing I want to do.. and yup, there's a concurrency bug I never would have thought of! I guess all that old code I wrote has bugs that I didn't know about at the time.
There are basically two reactions people have to this situation: (1) they're thankful that they learned something, their code is improved, and go about their day learning something new; or (2) feel frustrated and helpless that the old way of doing things doesn't work, and rage-quit to go write a "WHY RUST IS THE WORST THING SINCE MOSQUITOS" blog article.
Nit: it doesn't make it hard, it makes it ugly and explicit. `Arc<Mutex<Box<T>>>>` is not hard to use, it's just annoyingly verbose and ugly.
That's a low level construct, there are much nicer higher level sharing constructs, like channels.
Mission accomplished.
Yeah, this pretty much summarizes my experience. In most situations, the actual information I need to share between different contexts is quite small, and using a channel ends up being pretty clean. There are still times I need an actual reference counted wrapper around a mutex, but they're the exception rather than the norm, and even then, there are often ways you can reduce the contention (e.g. if `T` is a type you can clone, and you only need a snapshot of the current state of the data rather than preventing changes while processing based on that snapshot, you can just clone it, drop the mutex guard, and then proceed without needing to worry about borrows).
It is hard to use because you can’t just access the shared state. You have to annoyingly lock it, handle the guard object, etc. Each one of those layers has protocols.
Of course you have to lock a mutex. You'd have to do that no matter the language, right?
And that's what I meant by verbose/ugly. Each of those steps is usually an if let / else error. None of those steps are hard, but you have to do them every time.
Oh, plenty of people access shared state without proper locks all the time. Even experienced developers.
Heh. You're pedantically correct, the best kind. I meant "have to" in terms of "for correct operation you must" not "the compiler forces you to" since the latter isn't a thing in some languages.
> So many times I've tried to do something in Rust the old fashioned way, the way I have always done things, and been stopped by the compiler. I then investigate why the compiler/language is being so anal about this trivial thing I want to do.. and yup, there's a concurrency bug I never would have thought of! I guess all that old code I wrote has bugs that I didn't know about at the time.
This is also my experience. I've had dozens of times over the years that I've been confused about why Rust does something a certain way, but I don't think I can recall a single one where I didn't end up finding out that there was an extremely good reason for it. That's not to say that in every one of those cases, the design choice Rust made was the only reasonable one, but in the cases where it wasn't, the situation always ended up being more nuanced than it appeared to me at first glance, and what I would have originally expected would have implicitly made a significant tradeoff I hadn't considered.
I'm having trouble finding it now, but years ago someone had a quote that ended up getting published in the language's weekly newsletter that was something like "Rust moves the pain of understanding your program from the future to the present". It's extremely apt; most of the difficulty I've seen people run into when trying to program in Rust ends up being that they're forced to consider potential issues that in other languages they could have ignored until later, and then would have had to debug down the line.
That’s a very good quote.
There’s a handful of pain points that the Rust model does impart which are not fundamental. For example, unsafe code is required to get a mutable borrow to two different fields of a struct at the same time.
But really that’s the only example I can think of offhandedly, and I expect there are not many in total. Nearly all of the pain is merely the trouble of thinking through these issue upfront instead of kicking the can down the road.
The only other one I can think of is kind of poor ergonomics around "self-borrows"; it's a lot less common than I've felt the need to mutably borrow two fields from the same struct independently, but there have very occasionally been times where I've realized the simplest way to structure something would be to have one field in a struct borrow another. This is somewhat hard to express given the need to initialize all of the values of a struct at once, and even if you could, there are some complications in how you could use such a struct (e.g. not being able to mutate field `a` safely if it's borrowed by field `b`). Overall though, the things that Rust prevents me from handling safely because of its own limitations rather than them being fundamentally unsafe are quite rare, and even with those, they tend to be things that I would be quite likely to mess up in practice if I tried to do them in a language without the same safety rails.
>However, as already implied in my article, you can get most of the guarantees without losing your sanity.
Yeah sure, but what compares that gives you similar perf, safety, and language features to Rust? I'll use "safety" in a loose term to say "you really infrequently encounter odd memory safety issues". Go for example still has the occasional memory corruption issues with maps in particular although these don't show up too often and the race detector exists.
C# is probably the closest I can think of for AOT? I don't really know what the deployment story for a .NET application looks like these days though.
Go has some language design things that turn people off.
>but they are not the sole source of bugs in applications — as developers of Zed found out.
You called out Zed in the blog post as well but I've not seen the Zed devs expressing regret of using Rust. Is this just an assumption on your part? As someone who's written many UI applications with egui and one with GPUI, I've felt some minor pain points but nothing show-stopping.
I used to write a lot of C#. I used to write a lot of Go. I now write either and basically exclusively write Rust these days and a bit of C/C++ at work. The only time I've really felt the pain of `Rc<RefCell<...>>` gross types was recently when trying to port a game engine's data loader to Rust. It makes heavy use of OOP patterns and trying to emulate that in Rust is asking for a bad time, but I did it out of just out of trying to one-shot the migration and keep logic similar. Not fun, but I knew what I was getting myself into.
>Yeah sure, but what compares that gives you similar perf, safety, and language features to Rust?
I've already answered it in the original article — Rust is already here, and better language is not. Still, it will not make me say "it's the best option we have by now" — because it's not nearly the best option.
Performance? Lots of code is cold and not impacting performance much. You just don't need everything written in Rust or C++.
>You called out Zed in the blog post as well but I've not seen the Zed devs expressing regret of using Rust. Is this just an assumption on your part?
I'm kinda saying if I was a Zed dev I would have my pillow wet with tears at night. I know this because I participated in IDE development in C long time ago, and I was drowning in this whole low-level stuff all the time, I just could not do a single feature because I have to handle hundred of those other small things before the feature can work.
>As someone who's written many UI applications with egui and one with GPUI, I've felt some minor pain points but nothing show-stopping.
I have no idea what those applications were and how complex they were, so I cannot comment on it.
> It might be counterintuitive, but garbage collectors in multithreaded code can be very efficient.
It is indeed. But on the flip side, no other programming language is going to give you a compile error if you forgot to wrap you data into a mutex before sharing it between threads, and you'll either end up with a ConcurrentModificationException exception at runtime (Java) or with an undefined behavior.
But otherwise yes, there are plenty of situations where a GC is a totally valid solution. Just not for most of Rust's niche.
> It might be counterintuitive, but garbage collectors in multithreaded code can be very efficient.
What has garbage collector to do with multithreaded code? Once you have two or more threads which needs to share data, they need to sync and you'd end up using some kind of lock, which will affect the performance. GC doesn't make anything efficient or less efficient here. It might make the code simpler as you don't have to worry about allocation/deallocation, but I don't see how it's magically going to remove the lock.
> 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?
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).
> We actually had a recent Cloudflare outage caused by a crash on unwrap() function
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.
It was bad coding.
.unwrap() is not required to be used.
use:
if let Some(value)=something_to_unwrap{
}else{ // log an error and exit!! }
Fun fact: that's what an unwrap does. It panics, which causes the error to be logged and the thread ended.
And one of the fun things about how unwrap() does that automatically, is that if you are working with an orchestrator with retry logic, you won't need to (re-re-re-re-re-)write your own for the entire program - the orchestrator will see the error, log its output, and try again in high volume workloads, or move on to the next request - this is incredible and nice to use especially when a failure in one request doesn't need to fail the entire application for all requests.
I shy away from unwrap() in almost all cases (as should anyone!) but if you are running a modular system, then unwrap when placed strategically can be incredibly useful.
I think the commenter meant "return a Result<_>" instead of exit. Your snark is perhaps amusing, but not particularly charitable.
Maybe rust should put a function in the core library which does this! Send a PR!
https://doc.rust-lang.org/std/result/enum.Result.html#method...
Yet they spent ages trying to determine the actual cause of the failure, according to their postmortem, so I'm not sure what the advantage you're positing is?
Doing a naked unwrap() in a function that returns a Result is probably a crime against humanity. Like, this is the dumbest thing you could possibly do.
It has potential to be the new thing, since several details synergize to make this incident more powerful:
1. Previous claims that Rust code often just works after compiling.
2. Previous claims that low-level error-handling idioms like matching, using Result, etc improve code reliability.
3. Previous claims that using unwrap in example code is ok for brevity. Also, Rust developers would know not to use it in production code.
4. The fact that significant portions of the internet were taken down because a production unwrap from a big, mature player and one of the Rust early adopters.
Sure, Rust is not the problem here, but rather Clownflare being too big and not having their SRE processes fully up to par for their size. Perhaps they are simply too big to operate at the needed level of reliability. However, Rust anti-fans can easily ignore the above and simply press the issue and debate the minutiae of error handling, human reliability, etc. It’s surprisingly effective and might even catch the ear of management.
However, this article is overall not at the level expected of Rust anti-fans in 2025. I commend the author for trying, but they need to improve in several areas like providing iron-clad real-world examples, proving the required level of experience, focusing more on pain points like dependencies and the potential for supply-chain attacks, addressing reskilling issues and internal corporate politics, etc. There was a blog by a veteran Rust game developer a while back which single-handedly destroyed the enthusiasm for Rust in gaming. That is the gold standard of Rust criticism for me.
1. But the code did just work after compiling. The code said "This can never be an Err, and if I'm wrong, you are allowed to panic." And it did just that.
2. They do. If you use them, which they didn't.
3. It is. Let's not discard personal responsibility.
4. The error would've happened in any language, Rust debatably made it easier to find though.
I don't write Rust code myself because I simply don't write any code that requires this kind of reliability, and thus I haven't expended the effort learn it properly. But if I were to start such a project, I would still go for Rust and learn it properly. I also don't have a "favorite" language. I just pick whichever seems most appropriate for the project, any decent programmer should be able to pick up any non-esoteric language to the point of adequacy in a few weeks anyway.
.unwrap() was a huge mistake. It should be banned from release builds outright. It's the equivalent of dereferencing a null pointer in C or the NullPointerException in Java. All .unwraps() should be replaced by .expect("uniquely identifying message") immediately and preferably the compiler checks that the expect messages are unique within a crate and issues a warning. Debug builds should by default give .unwrap() and .expect() a tiny chance, like 0.1%, to trigger anyway, even when the Option is Some (opt out via configuration).
To my knowledge, the only difference between `unwrap()` and `expect()` is that the latter takes a custom error message, whereas the former generates a generic error message. In both cases the resulting error message includes the filename and line number of the panic. Both can also generate stack traces if you set `RUST_BACKTRACE=1`, unless this was explicitly disabled at compile time.
So if you want to ban `unwrap()`, then you should probably also ban `expect()`, and make sure to handle all possible cases of Err/None instead.
> Debug builds should by default give .unwrap() and .expect() a tiny chance, like 0.1%, to trigger anyway, even when the Option is Some (opt out via configuration).
I'm trying to understand what you're proposing. Are you saying that normal debug builds should have artificial failures in them, or that there should be a special mode that tests these artificial failures?
Because some of these failures could cause errors to be shown to the user, that could be really confusing when testing a debug build.
I guess they are advocating for exhaustive branch testing.
>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.
So why do they need Rust then? What advantages does it provide? That was the main point of the article — we all wanted a better language, but got another crappy one instead.
> So why do they need Rust then? What advantages does it provide?
That Rust didn't prevent one error in one specific instance does not mean that Rust didn't prevent any errors across any instances. Nor does it mean that Cloudflare didn't benefit from Rust in some way(s) elsewhere.
For example, from one of Cloudflare's previous blogposts [0] (emphasis added):
> Oxy gives us a powerful combination of performance, safety, and flexibility. Built in Rust, it eliminates entire classes of bugs that plagued our Nginx/LuaJIT-based FL1, like memory safety issues and data races, while delivering C-level performance.
[0]: https://blog.cloudflare.com/20-percent-internet-upgrade/
To prevent all the other potential memory safety bugs that didn't crash prior to this one?
If any language would've had this bug, why is Rust being singled out? If the software was written in Go, would the bug get the same attention?
No programming language should get flak for a bug that is not the fault of the programming language. This is Cloudflare's problem.
In Go, if one would ignore the error, it could result in a panic or the program would continue with some unexpected state. Go projects work on an honour system and either return Nils with errors or empty structs.
The same case in Go would’ve probably been a nil panic.
Before the outage, Cloudflare had Cloudbleed: https://blog.cloudflare.com/incident-report-on-memory-leak-c...
The move to Rust was partly motivated because it prevented that entire class of errors. No more out-of-bound reads, or data races. The compiler audits these missed spots.
Now, you could say a managed memory language would suffice as well. Perhaps it could. But we needed performance, and no memory-managed language met those performance needs then or today.
I get you're making the case that Rust isn't perfect for all use cases, but Cloudflare's scenario is the exact corner case your argument falls apart in: we needed fast and safe in an environment where not being fast or safe had real business consequences, and nothing else except Rust gave both.
You should familiarize yourself with the prevention paradox.
If you're going to criticize something, at least do it properly.
That Rust produced a predictable and deterministic way of failing, while in C++ the equivalent code of accessing an uninitialized value without verifying it beforehand would have resulted in entirely unpredictable behavior whose reach is entirely unbounded.
Moreover, now they realize this is an issue for them, they can just do "Ctrl+F unwrap" and fix each instance. Then they can put a hook on their commits that automatically flag any code with "unwrap". In some languages where you're allowed to just ignore errors, you could fix the proximal bug, but you'd never be sure you weren't causing or ignoring more of the same in the future -- how do you search for what isn't there?
Due to the unfortunate naming of unwrap_or and friends it's a little (but only a little) more complicated than ctrl-f.
You can also forbid unwraps as part of clippy.
Not really. It's just "unwrap(" instead.
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.
> The cloudflare bug was not caused by rust
Yeah. Rust’s Option::None as like null in C++. Unwrapping an option is like checking if something is null and crashing. This "crash from an unwrap" is just a null pointer exception / segfault in any other language. The same bug would be trivial to write in any other language, and with more or less the exact same result. Its just - weirdly news because it was rust code. What?
> 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.
Exactly. I’ve spent years with rust and my complaints are very different. Well, I still wish it compiled faster but all the other stuff is noobie problems. As someone with more experience, my frustration points are things like how async blocks do compiler magic you can’t write yourself. I hate unnameable types. I think Pin is confusing and weird. And the syntax for interacting with raw pointers is unnecessarily inconvenient and ugly.
Yes, rust makes programs with a lot of shared mutable state awkward to write. So don’t program like that. In general, if you write code in language X as if it were a bad version of language Y, you're going to have a bad time. The right question here is if the "rust way" of thinking about your code results in a beautiful program. You can't answer that if you go in with too many preconceptions of how programs should be designed.
Rust makes it very, very easy to .unwrap() something, making panic-crashes the default error handling behavior for a lot of rust programmers. But it does this without, e.g., Erlang's reliability services that will auto-relaunch code that crashes. The end result is NOT a very good user experience.
I say this as a Rust advocate and daily Rust programmer, btw.
When it comes to distributed services, unwrap is likely the behavior you do want, because the service is being run by a scheduler that detects failures, and a panic would be tied to a metric and page an sre. My read of the situation is that they were overwhelmed by their dashboards which made it harder to identify the root cause, but that is a common situation for these kind of events. I'm pretty sure that this exact sequence of events will never happen again to them because they will adjust their observability to be clearer, should this ever happen again.
For libraries and cli tools, you don't want panics except for things that are broken beyond any recovery. A cli tool should not panic directly, instead emitting human readable errors.
It should probably have a different name.
But nil panics in Go are even easier, the compiler doesn’t even require you to opt in. I deal with that every day.
The Cloudflare bug was unwrapping a Result::Err not an Option::None.
Both Option and Result can be unwrapped and - to some extent not coincidentally - both can also be subject to the Try operator (?) which is arguably more correct here than unwrap because this can fail and perhaps the caller will have some plan to recover.
My list of peeves would be very different from yours. I would like to prohibit move of the dodgier as casts (requiring that you write out the conversion call you actually meant explicitly and then handling any edge cases) for example.
What sort of "interacting with raw pointers" are you thinking of that's too inconvenient and ugly for your liking?
> Both Option and Result can be unwrapped and - to some extent not coincidentally - both can also be subject to the Try operator (?) which is arguably more correct here than unwrap because this can fail and perhaps the caller will have some plan to recover.
I guess its equivalent to Go code like this:
Or in C: If someone wrote code like that and the program crashed, nobody would attack Go or C. In all these cases (including rust), the programmer is expressing clear, explicit intent for the program to panic if the call failed. I've seen some people say .unwrap() should be named .unwrap_or_panic() or something to make that more clear? I dunno. It seems like a nothingburger to me. A buggy program crashed. They'll do that.> What sort of "interacting with raw pointers" are you thinking of that's too inconvenient and ugly for your liking?
I have 2 complaints. First, I wish Rust had a -> operator or something like it. This sort of thing is horrible:
Secondly, rust's aliasing rules make writing pointer heavy code very difficult. I like to run my unsafe code through MIRI to make sure I'm not doing anything bad, and its incredibly subtle.Here's an unsafe function which manages the internal state of a skip list:
https://github.com/josephg/jumprope-rs/blob/3981256e4e741d8b...
This code is insanely fragile. There are multiple pointers to different elements floating around. The only way I got miri to calm down was to dereference the node pointer constantly. Eg:
Basically everything else I tried caused obscure aliasing problems. I think if I rewrote this code today I'd probably use a Vec and safe rust instead. I can much more confident write correct C code than correct unsafe rust code. I wish it were the other way around.As a general principle, unsafe rust should be as simple and easy to reason about as possible so we can spot security problems. But rust's syntax makes unsafe code very complex. I don't think this complexity is in any way necessary.
I see what you mean for -> although personally I haven't missed it (I spent many years writing C) I don't write much pointer twiddling in Rust so I'm the wrong person to have an opinion.
However surely the aliasing is actually a problem and so MIRI is annoyed because what you wrote might be wrong? If we hang on to (*node).first_next() but somehow node changes, we're no longer talking about the same thing, it's exactly the aliasing problem.
I'd have to (which I have not) examine in detail how your code works to offer an opinion beyond speculation, but I think my instinct is sympathy for the "Don't write aliases" approach.
> I think my instinct is sympathy for the "Don't write aliases" approach.
Yes, requiring that nothing alias it’s much more conceptually elegant. But as I said, in practice it makes programming extremely treacherous. There are no warnings when you alias. No errors. 99% of the time you’ll get a working program with no bugs every time you build. You’re just - quietly - at the whim of llvm. Maybe it won’t compile correctly on some other architecture. Maybe a minor compiler bump, or different flags, will make your program totally broken. The only way to discover there’s even a potential problem is by running the code through MIRI.
I get why it’s like this but I think it’s a mistake. I think unsafe rust should be at least as expressive and pleasant to work with as C. Having quiet foot guns here seems antithetical to rust’s philosophy of safe ergonomic programming.
Err, you can't use `?` with `Option` unless I've really missed a big feature somewhere. You'd have to map it to a `Result` then unwrap, but at that point you still need to define an error type.
https://doc.rust-lang.org/std/option/enum.Option.html#impl-T...
I guess you've "really missed" this feature or more likely you are considering only the case where our function signature says we return Result and so early returning Option won't compile.
Because the modern "try v2" operator is a trait, it is implemented for Option, Result, and ControlFlow plus Poll variations.
Historically its ancestor the try! macro was provided only for Result, but that's a very long time ago now.
I guess? If it's still languishing in nightly I'm not sure I consider it usable; I'm aware some people are fine to run nightly but I keep to stable releases.
So, all of Try is unstable. This means your stable Rust isn't allowed to implement Try for your own custom types, however the syntax is stable, so since Try is implemented for all of Option, Result and ControlFlow, those all work with the ? syntax even though that implementation is marked unstable.
Let me give you another example you've probably used without realising it, when you write password.contains("foo") in Rust. Why can you write "foo" there? Rust doesn't have overloading, and yet you can pass strings, characters, and functions including lambdas - how can this work? They all implement core::str::pattern::Pattern, an unstable trait used to deliver this functionality for all string matching.
In fact mechanically what's happening here for Try is that ? always worked for Option and Result, the "try v2" feature isn't about the syntax at all, it's about the behind the scenes implementation of that syntax. But that's not important, the syntax is promised and the final implementation will almost certainly be tryv2 or something very similar.
TIL. Thanks for noting!
You have missed a big feature! They added support for that like a year ago or something.
I guess? If it's still languishing in nightly I'm not sure I consider it usable; I'm aware some people are fine to run nightly but I keep to stable releases.
No it's stable.
Years ago. In April 2021 this starts to appear as part of Try v2 implementation work.
> Compile speed. Why do people care so much?
Ardour is a real-world, mid-size project. About 1.3M lines of code, almost all of it C++. On the fastest typical x86_64 systems, it builds in about 1.5mins, on an M3 it builds in about 3.5mins, on a somewhat older x86_64 16 core system it builds in about 7.5mins.
If you ever touch libs/ardour/ardour/session.h or libs/pbd/pbd/stateful.h, you're in for an almost complete recompile. If you touch libs/temporal/temporal/timeline.h, same thing. That's just the day to day work of being a developer of a native desktop application - nothing to do with CI or releases.
That's why some of us care.
Your point about compile times is very dismissive and wrong, but I agree aside from that. It's worth noting that the Rust team explicitly tracks, monitors and limits regressions in, and actively optimizes for compile times, and Rust community surveys always ask for better compile times. This is clearly a significant issue, and while Rust is never going to compile as fast as C or Pascal, it can and will improve so that it becomes more usable.
> Mutable shared state: make bad designs hard to write.
Also makes good designs hard to write, designs that can be significantly more efficient.
Passing messages is not a universal solution to shared mutable state. It is great for certain patterns but suboptimal for others.
Wrong, it makes good designs easy to write with clear safe APIs. If you know what you are doing just create a safe wrapper over unsafe functions and do what you need.
For example you can just write a lockless triple buffer for efficient memory sharing and wrap the unsafe usage of pointers with a safe API. now you only need to pay attention to those specific unsafe calls.
> Wrong, it makes good designs easy to write
It encourages good designs but it does not make them easy to write, but that's somewhat the point. Its not trivial to design a safe API that pushes performance limits.
> just write a lockless triple buffer for efficient memory sharing and wrap the unsafe usage of pointers with a safe API
This isn't practical or pragmatic.
And I say this as someone who likes rust and develops in it every day.
> - 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?
Even if you know you're code compiles, it's often easier and faster to validate the logic or complex interactions by running the code. In large (and even not so large actually) projects, debug builds can be painfully slow, even on good hardware. It's important to have a tight feedback loop so that you can interate quickly.
>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.
What's the largest Rust-based public codebase so far? Rustc with like 1 million lines of code including all the dependencies in all the languages? Zed IDE has 800k lines. Incremental compilation seems to work fine at this scale, but things become messy above it. Most people prefer to not exceed the limit.
>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.
People think BEAM (Erlang/Elixir) does not have shared mutable state because the programming model says so, but it actually has some mutable shared state transparently under the hood i.e. implementation details and runtime. BEAM processes all run in a single OS address space, they are not even separate threads but async tasks spread out across OS threads — and still per programming model of the language those are "shared nothing". So in the end BEAM is a very good abstraction on the partially shared mutable state.
And no, in BEAM remote messaging is not nearly the same as local messaging. For example, you don't have built-in supervision trees on remote, and ETS is also local-node-only.
I do agree that hardware model of shared mutable state is inherently problematic, but we don't have other commodity CPU-s yet — you have to handle the shared mutable if you wanna be close to hardware.
>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.
Well, at least you confirm that the complexity is real. Don't get my criticism to close to the heart though — I did exaggerated the problems a bit, because someone needs to counteract the fanboys.
> 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
This isn't true, no matter how much people keep saying it. Unsafe does not scope bugs to the block, or even where you have to look for bugs. Just having unsafe in your codebase means changing code outside the unsafe block could cause UB.
Doesn't mean I think it's worth complaining about, there's really no better way for Rust to do this without sandboxing memory.
If changing the safe code causes UB, the actual bug is in the unsafe code.
This is very true from outside an encapsulation, but within the private implementation of a type there may be safe Rust that's required to uphold some assumptions made by the unsafe Rust [if there is some] and while in theory the bug is in the incorrect assumption made by the unsafe Rust in practice we're going to fix the "safe" code which broke our assumption instead.
Nope. I would encourage you to actually read what unsafe does, because nowhere in the Rust docs does it say "scopes bugs to the unsafe block"
See the below code. The unsafe code is doing exactly what it's supposed to. The safe code frees a value while it's being used. This compiles. There's nothing to change here in the unsafe code.
```rust
```The unsafe code is not fulfilling the contract of "unsafe", which requires the coder to uphold the memory safety rules as seen from outside. make_slice is putting a very wrong lifetime on the slice it returns.
My whole comment here is that safe code has to care about how it uses data from unsafe code. That's pretty evident from my example and from reading from_raw_parts. How would you fix this by only editing the code inside the unsafe block? Because you said the problem is the lifetime. That's outside of the unsafe block.
> The unsafe code is not fulfilling the contract of "unsafe", which requires the coder to uphold the memory safety rules as seen from outside
It's the exact opposite. From the Rust docs. [1]
> By calling an unsafe function within an unsafe block, we’re saying that we’ve read this function’s documentation and we take responsibility for upholding the function’s contracts
The caller here is what is violating the contract. It's not the unsafe code's job to do that. How could it? It's just making a slice, it doesn't know what from. It can't guarantee a slice it makes is ANY kind of lifetime. If it could, it wouldn't require unsafe.
We don't have to use a static lifetime to have this bug:
Lifetime annotations are just annotations for the compiler, but they mean very little when using unsafe. I wrote a bad lifetime to illustrate that Rust doesn't care. Normally, the compiler would make sure your lifetimes make sense, but not with unsafe. Because it's the calling code that has to care.Yes, if you change the function signature and require it to receive the vec so you can see the lifetime, you could technically fix it from this function. That's the only way to get the right lifetime.
So yes, as long as you change your function so much you can basically remove unsafe, you can fix it from the function.But you can't do this in scenarios where you'd actually want unsafe, like FFI, custom data structures, etc. You don't have the same lifetime information available to you.
[1] https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html#call...
> The caller here is what is violating the contract.
"The caller" of the unsafe function is the unsafe block in make_slice. And yes it's violating the contract.
> How would you fix this by only editing the code inside the unsafe block? Because you said the problem is the lifetime. That's outside of the unsafe block.
If it's locked into returning a static lifetime, then the only fix is to return a slice into a static allocation.
Is this the functionality you wanted? Probably not. But an unsafe block having an awkward API isn't an excuse to violate safety. Sometimes the only answer is to say no. Calling from_raw_parts this way is a clear bug.
> How could it? It's just making a slice, it doesn't know what from.
It could know more if you added more to the unsafe block outside the call to from_raw_parts.
> It can't guarantee a slice it makes is ANY kind of lifetime. If it could, it wouldn't require unsafe.
> as long as you change your function so much you can basically remove unsafe, you can fix it from the function.
from_raw_parts exists for situations where the coder can guarantee that the lifetime is valid (no matter what safe code does), but the compiler can't guarantee it (because it's not smart enough).
It's not there for situations where you make the safe code promise to behave.
It does have a lot of uses, in places that do need unsafe. You just happened to make an example that doesn't need it.
It's not a bug until main uses it incorrectly.
The lifetime is outside of the unsafe block. I can change it from static and we still have the same bug.
> It's not a bug until main uses it incorrectly.
It's always a bug. The lifetime is wrong.
The mere ability to "use it incorrectly" and break memory safety is evidence of a bug. Safe rust in a program without unsafe can't use anything incorrectly in that way. Safe rust in a program with appropriately careful unsafe can't use anything incorrectly in that way.
> The lifetime is outside of the unsafe block.
The unsafe block uses the types from the surrounding function, so you can't change those types without double checking the unsafe block is still valid.
> I can change it from static and we still have the same bug.
Change it to something correct and have the same bug?
Because your continued examples look like no. If you make the lifetime arbitrary then it's still messed up, and if you get the lifetime off the vec then the bug is fixed.
Forget lifetimes, do this. It's a bug. It's in the safe code. You fix it in the safe code, because it misused unsafe code.
Okay I ended up replying to this example over here: https://news.ycombinator.com/item?id=46051496
> How would you fix this by only editing the code inside the unsafe block?
In this case, the solution is to mark make_slice as unsafe. This should make sense if you think about it for a second, because it's a thin wrapper around an unsafe function. If it were possible to make a function which did what std::slice::from_raw_parts does safe, it wouldn't be marked as unsafe.
> It's the exact opposite. From the Rust docs.
The docs you quote say the exact opposite of what you claim. Where do you do call the unsafe function in an unsafe block? In make_slice, not main.
> So yes, as long as you change your function so much you can basically remove unsafe, you can fix it from the function.
The actual use case for std::slice::from_raw_parts is for when you control the pointer and length and thus can guarantee that they're valid (specifically, by encapsulating them and making sure no safe functions can get them into an invalid state). For example, std::Vec::as_slice uses it [1] to get a slice from the pointer to it's managed buffer and it's stored length.
> FFI
There are two possible ways FFI could cause memory safety violations despite being called from safe code:
- The safe wrapper makes incorrect assumptions about the contract of the functions it's calling (e.g. maybe it assumes that a c function returns a pointer which it's the caller's responsibility to free, but is actually freed by the c code). In this case, the bug is in the unsafe rust. - The foreign code violates it's contract (e.g. same as above, but the documentation of the c code claims otherwise). In that case, the bug is in the foreign code.
Either way, the memory safety bug is not in safe rust.
[1] https://github.com/rust-lang/rust/blob/7934bbdf84a6b9a30297c...
> The actual use case for std::slice::from_raw_parts is for when you control the pointer and length and thus can guarantee that they're valid (specifically, by encapsulating them and making sure no safe functions can get them into an invalid state)
Right...so you fix it from the safe code, because the safe code is in charge of using from_raw_parts correctly.
> Either way, the memory safety bug is not in safe rust
This might just be a difference of semantics between us, but I really don't see how you can arrive at that conclusion. Just remove the function entirely and let's use from_raw_parts directly. The bug is literally not in unsafe, it's when we drop the vec after making a slice from it. To fix this, we would not change anything in unsafe.
> Right...so you fix it from the safe code, because the safe code is in charge of using from_raw_parts correctly.
Safe code cannot corrupt the Vec variables to make Vec do something incorrect.
> To fix this, we would not change anything in unsafe.
You're supposed to.
Some coders might implicitly count the rest of the function as trusted code that's part of enforcing the invariants of the unsafe code. So there's an implied "unsafe" block that fills up the rest of the function, as far as responsibility goes.
I won't argue one way or the other on that philosophy, but if anything outside the function with the unsafe block is part of enforcing invariants, then that is clearly wrong.
If you subscribe to that philosophy, then you could say the drop is the problem in this single-function case. But in the original the bug is still inside make_slice, because make_slice is unleashing a fragile and uncontrolled slice into the safe world of main.
(There might be some more subtleties when it comes to class API boundaries but I don't want to dig through that right now, it's not relevant to the important part of this conversation.)
>> To fix this, we would not change anything in unsafe.
> You're supposed to.
To me, it just sounds like we're disagreeing on definitions. You can view it as unsafe corrupting the vec, I don't disagree with that, but it's the way the safe code coordinated the unsafe code that caused that problem.
I'm happy to be shown a different way. Would you kindly show me how you would fix this in the unsafe block only?
> Some coders might implicitly count the rest of the function as trusted code that's part of enforcing the invariants of the unsafe code. So there's an implied "unsafe" that fills up the rest of the function, as far as responsibility goes
That's essentially what I'm arguing.
> but if anything outside the function with the unsafe block is part of enforcing invariants, then that is clearly wrong
What is clearly wrong? I'm not saying none of it is wrong, I'm just saying unsafe allows you to make bugs outside of it. And yes, it can happen at arbitrary depth, not just in the function containing unsafe code.
> Would you kindly show me how you would fix this in the unsafe block only?
I'd probably hold a reference to the vector or something.
> That's essentially what I'm arguing.
The thing is it's only the safe code in the same function as the unsafe block that you could call responsible in any reasonable sense.
In the original version the main() code cannot be blamed for dropping a vector 'early', because it didn't invoke this scheme that requires the vector to be kept alive, make_slice did. It was make_slice's responsibility to guarantee the underlying allocation stays alive, and it didn't do that.
> What is clearly wrong? I'm not saying none of it is wrong, I'm just saying unsafe allows you to make bugs outside of it. And yes, it can happen at arbitrary depth, not just in the function containing unsafe code.
If you're putting responsibility on code in the same function, you're not really treating it as safe code. There's an unsafe{} around the entire function body that you should have written if you were going for maximum clarity.
If the depth goes any higher, you screwed up. It should be impossible for safe code outside the function to use your code and cause a memory error. If it's not impossible then that's a bug in the unsafe blocks (or the function with the unsafe blocks).
> I'd probably hold a reference to the vector or something
In a way that only changes the unsafe block?
> make_slice's responsibility to guarantee the underlying allocation stays alive, and it didn't do that
We çan talk about the simpler code example. How can my unsafe block make sure an allocation stays alive past the unsafe block itself?
> If you're putting responsibility on code in the same function, you're not really treating it as safe code. There's an unsafe{} around the entire function body that you should have written if you were going for maximum clarity
I'm not talking about what should've been done, I'm saying this is something to be aware of on projects with multiple people who may not catch something like this. People think bugs cannot happen in safe code. I just showed it happening. The bug was not in unsafe, or in the drop, it was in println.
> How can my unsafe block make sure an allocation stays alive past the unsafe block itself?
Put it in another data structure or something?
Listen, if you can't make the invariant work, then you need to change the function. An unfixable unsafe is not an excuse to allow errors
> I'm saying this is something to be aware of on projects with multiple people who may not catch something like this.
It's good to be aware but put the blame in the right place. It's the unsafe code that's actually at fault. If you are seeing corruption, look at the unsafe code first with an adversarial mindset.
> The bug was not in unsafe, or in the drop, it was in println.
N. O.
Any unsafe code that outsources invariant enforcement that affects memory safety to safe code has bugs. There's wiggle room on "outsources" but that's the only wiggle room.
I think one can argue make_slice is in fact at fault here since it's unsound (i.e., it doesn't enforce the requirements of from_raw_parts() and so allows safe code to invoke UB) and therefore either should be marked unsafe or should actually enforce the requirements of from_raw_parts().
That being said, I think in this context that's more of a nitpick since you're right in stating that bugs that result in UB need not be scoped strictly to unsafe blocks.
Internal use of unsafe requires securing the safe code at the module boundary. However, the design of unsafe still greatly reduces the burden of memory safety, both when it is and isn't used directly. The specific semantics of Rust aside, unsafe is more or less the ideal way for a language to express unsafe escape hatch constructs.
> Internal use of unsafe requires securing the safe code at the module boundary
Not even that, because you can pass data structures from unsafe code at arbitrary depth.
If the goal is to make a safe abstraction, which is what I'm talking about, proper use of visibility and safe code at the module boundary encapsulates the unsafe code soundly.
You seem to be talking either about improper encapsulation or unsafe that is intended to be exported and used unsafely. Or perhaps some method that is not sound according to the language.
This is true. If you consider unsafe memory to be a separate region in Rust, your safe Rust code can still have pointers to unsafe memory. The only solution to this problem is to perform some sort of validation of the returned data structures every time they are returned by an unsafe block.
You really have to compare articles like this, which are just a bunch of hand waving around the author's biases, against articles with more concrete statements like the Android team finding a 1000x reduction in memory vulnerabilities compared to C/C++. Thanks for your opinion but I'm going to weigh the people who actually use the language more than you.
Hard disagree.
For my reality of developing for smaller projects than Android, I will absolutely weight Android team's opinion less than the opinion of smaller projects.
Trying to mimic FAANG engineering practices is a fools endeavour that ranges between naiveness at best and CV padding at worst.
The objective data they provided is opinion now?
FAANG engineeers can't code for shit, but the one thing they did get right was when they jumped on the Rust bandwagon
The android team wasn't comparing like to like, though people seem to gotten the impression they were.
The author says "Rust crashes all of the time" and then goes on to invoke the Cloudflare unwrap() as an example of that. Uhhhh... but that was clearly a programmer error, right? Ignoring the possibility of a Result being Err instead of Ok is not something the language is supposed to protect you against.
By coincidence I was talking to one of Cloudflare's engineers this weekend† and they actually argued that the unwrap() isn't the problem per se, that instead it's just wrong to go from "We don't know if this data works" to "Everything is broken" without the step where you check that data works - and that's still true if we're doing this once per minute not once per month.
I argued that requiring expect("expectation") calls rather than unwrap() instils the discipline to consider what you're expecting and thus why you think we won't panic - to write the text in the expect call, but I did not convince them and they remained sure that what Cloudflare needs is better deployment discipline not improved engineering practices.
† It is a coincidence that they work for Cloudflare, it was quite intentional that I spent much of my weekend with them, we were playing video games.
Screw discipline, it’s a tooling problem. Making canary rollouts with automatic rollback the default would take a lot of investment up front, but then would make discipline at release time a non-factor.
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.)
Yeah, I don't really get that argument if that's what the author is trying to claim. If there's a language where a programmer mistake can't have bad consequences, C++ isn't it, so either it would need to be combined with an argument that C++ programmers are just better (which seems like a bold claim that would require evidence, on top of not really being about the language anymore), or it isn't really a point against Rust.
There are programming languages/models/runtimes that crash and recover, there are models that gracefully degrade. Rust cannot recover. Neither can C++ in many cases e.g. when you have an exception in a destructor then it's a guaranteed `std::terminate`.
Do note that C did not have such a flaw built into language — C++ authors invented it and Rust inherited this flaw (the authors simply did not feel like it's a flaw). I mean specially designed embedded C code can survive total RAM erasure and still perform some meaningful work (with CPU registers and ROM intact). Or compare it to BEAM that can have processes crash all day long and still continue to work. "Memory safety at all cost" is not a practical requirement — it's theological.
> Rust cannot recover.
catch_unwind exists for a reason.
> e.g. when you have an exception in a destructor then it's a guaranteed `std::terminate`.
You can throw in a destructor [1]. You just need to mark that destructor noexcept(false). You do get a guaranteed std::terminate if an exception escapes a destructor while unwinding is already underway, though.
> Do note that C did not have such a flaw built into language
assert() says hi?
> I mean specially designed embedded C code can survive total RAM erasure and still perform some meaningful work (with CPU registers and ROM intact).
Why doesn't a similar argument apply to "specially designed" Rust?
> Or compare it to BEAM that can have processes crash all day long and still continue to work.
Again, nothing stops you from writing Rust that does the same.
[0]: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
[1]: https://cpp.godbolt.org/z/ao4cf3zrr
>You can throw in a destructor [1]. You just need to mark that destructor noexcept(false). You do get a guaranteed std::terminate if an exception escapes a destructor while unwinding is already underway, though.
Come on, please tell me you don't do this in your code. Formally you are correct, but there are many things in C++ that should have better not existed.
>Why doesn't a similar argument apply to "specially designed" Rust?
Because it would lose most of the Rust properties by that time. C code with fixed memory layout, on the other hand, is ideomatic and was widely employed in the past. It's still being employed in embedded. I'm not saying that you are wrong though, there might be people optimizing Rust for this very purpose, but I'm not aware of such an effort.
>catch_unwind exists for a reason.
>>Or compare it to BEAM that can have processes crash all day long and still continue to work.
>Again, nothing stops you from writing Rust that does the same.
Who's gonna GC the poisoned garbage left in undefined state after the crash? I'm not saying it's impossible — I honestly have no idea whether safe recover is possible in Rust, but from what I know it's rather in middle of "not possible" and "not viable".
> Come on, please tell me you don't do this in your code.
I don't, but that's not to say that I think it should never be done.
> Formally you are correct, but there are many things in C++ that should have better not existed.
Sure, but I think it's important that one should do their best to be correct and/or precise.
> Because it would lose most of the Rust properties by that time.
Perhaps for specific bits of code, but that doesn't necessarily require that your entire codebase give up on safety. Part of Rust's value is in isolating unsafe stuff to specific sections of your codebase both so the rest of the code can make use of Rust's guarantees and so if/when something goes wrong it's easier to pinpoint the problem.
Not to mention if you're talking about "specially designed" codebases in the kind of situation you describe you're almost certainly not in pure-C-land either (e.g., standard C doesn't have the concept of CPU registers, so if you really need to stick to what's in registers you're going to have to resort to compiler-specific extensions and/or assembly). If you're willing to allow the necessary extensions for C, it's only fair that you do the same for Rust.
> I'm not saying that you are wrong though, there might be people optimizing Rust for this very purpose, but I'm not aware of such an effort.
There's a reason no_std exists. Low-resource embedded use has been a design focus since well before Rust's 1.0, and those considerations have continued to influence its evolution since - for example, Rust's async design is the way it is specifically to ensure it is usable in limited-resource environments.
> Who's gonna GC the poisoned garbage left in undefined state after the crash?
Whatever supervising process/thread you write/designate, if that kind of recovery is important to you? I don't think there's anything about Rust that precludes you writing such a thing.
Not to mention, must there be "poisoned garbage" in the first place? I don't think it's strictly necessary that such a thing be produced after a crash even if you ignore the fact that part of the reason unwinding exists is to clean things up even while crashing.
> but from what I know it's rather in middle of "not possible" and "not viable".
I'm curious how you came to that conclusion. It seems wrong both on a theoretical level (Drop/unwinding/catch_unwind should obviously suffice for at least some cases?) and on a practical level (tokio can recover from worker thread panics just fine?).
Nothing forces you to panic in Rust any more than anything forces you to call abort() in C.
is conceptually no different to: don't write either if you don't want to halt.> Rust cannot recover
Recoverable error mechanism in Rust: https://doc.rust-lang.org/std/result/enum.Result.html
> Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times.
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.
> Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times.
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.
>Its compilation is slow. I mean SLOW.
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
I am not too familiar with D, but it seems that D's borrowing system is somewhat different than Rust's, given that it is not the focus of how D is implemented and used. This means different design tradeoffs.
There are appropriate ways to contrast D with Rust and illustrate where D is stronger, but it is inaccurate to say "Rust has borrowing; D has borrowing" and conclude that they are comparable in this sense.
>"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."
Indeed, there are languages that have generics, compile blazingly fast, and still have good runtime performance. Go lang is another good example, although not perfect too. If only Rust designers did a single thing to make it compile fast instead of "eventually".
"Generics" is not why Rust compiles slowly. Rust had certain design decisions and implementation details that impact compile times significantly. Do not misrepresent them and pretend that the Rust developers are incompetent or malicious. By doing so, you invite discourse as ideological and uncritical as that of Rust fanatics, however many or few there are.
>Do not misrepresent them and pretend that the Rust developers are incompetent or malicious.
I'm sorry, but I sensirely think the Rust designer did a sloppy work by reimplementing C++ flaws with a new syntax. The history repeats itself, the same pathological mechanism once driving C++ development now drived Rust — I mean large enterprise wanting to change everything without changing nothing, the new tool that would feel like the old tool. They did not really invent some new model, look at std::shared_ptr, std::mutex, move semantic — it was already in C++ before the prototype of Rust. The "share immutables, lock mutables" model was a holy grail of C++ concurrency caused by the way STL worked — and STL is not nearly the only container library in C++.
Okay, what's your take on why exactly Rust compiles slowly?
Rust certainly takes after C++, but it's not the same. It's more like C++ if it was made today. For instance, Rust's destructive move semantics are the better default. (However, Rust making everything moveable by default is a bit of a drawback.) I don't understand your point about std::shared_ptr, std::mutex, and the immutability/mutability model. These are not C++ constructs; they are general programming constructs that C++ has an implementation of. Rust does not claim to have some innovative take on reference counting or locking. However, Rust's borrowing is an improvement (by default) on managing shared mutable state. Rust is not Carbon, or whatever new C++ variant is out there; it is a backwards-incompatible language that offers better ways to do many of the things C++ is used for.
> Okay, what's your take on why exactly Rust compiles slowly?
It's not "my take". https://www.pingcap.com/blog/rust-compilation-model-calamity... is a good resource on this.
> It's not "my take". https://www.pingcap.com/blog/rust-compilation-model-calamity... is a good resource on this.
I think one interesting thing that could be explored more is what aspects of Rust "inherently" result in slow compilation (i.e., if you changed said aspects to improve compilation speeds then you end up with a "different" language, assuming some hand-waviness with respect to equivalence here) and what aspects are practically and/or theoretically improvable.
For example, rustc's reliance on LLVM for optimization is a well-known source of sluggishness, but I wouldn't classify that as "inherent" since Rust could use a different backend that works faster (e.g., Cranelift) and/or be more efficient about the IR it emits. Something like monomorphization, on the other hand, is a more in a grey area since it's (as far as I know) essential for Rust to meet its performance goals, but IIRC it's not out of the question for the compiler to implement generics using a different strategy instead, which might be viable as an opt-in tradeoff.
There are at least three separate things that rustc and cargo could do to significantly improve compilation speed, but they are complex engineering efforts that require time and engineers being paid to work on full-time. They are: doing what zig does to compile only items that arr reachable, which requires making rustc reentrant to stop after name resolution and cargo more complex to pass used paths through subsequently, leveraging an incremental linker and have rustc only codegen the binary patch instead of the whole binary and have the linker calculate the patch, and caching proc-macros and treat them as idempotent (likely as opt-in). There are of course others, like pre-compiled distribution, better intra-rustc parallelism or feature cfg handling, but those have more open questions and require additional design work before I could claim they're attainable.
Oh, I hadn't heard that you guys are looking at Zig-style "targeted" compilation (for lack of a better phrase). That sounds like it entails quite a bit of infrastructure work. Is there a GitHub issue I can follow to keep an eye on progress?
Out of curiosity, have there been any interesting pondered/proposed avenues for speedup that were rejected because they would result in too much breakage, violate a core tenant of Rust (e.g., require a runtime to be usable) or other reason that is "inherent" to Rust?
You can see epage's replies to my copy of this comment for an idea of the open questions: https://hachyderm.io/@ekuber/115605792856416650
You can look at what is currently effectively staffed at https://rust-lang.github.io/rust-project-goals/#flexible-fas...
We discussed a lot of these last May in person. Haven't kept track of who's doing what on these fronts.
> have there been any interesting pondered/proposed avenues for speedup that were rejected because they would result in too much breakage, violate a core tenant of Rust (e.g., require a runtime to be usable) or other reason that is "inherent" to Rust?
Yes, but I haven't been part of all of them and can't ellaborate much here. Opening a thread in internals.rust-lang.org with that question might get some good info sooner that I could.
> You can see epage's replies to my copy of this comment for an idea of the open questions: https://hachyderm.io/@ekuber/115605792856416650
Those are some interesting discussions there! Decent number of things I hadn't considered.
> Opening a thread in internals.rust-lang.org with that question might get some good info sooner that I could.
I'll have to see about setting signed up, then (or finding my old credentials; don't remember if I ever had any).
Ocaml compilation is also very fast, and it has generics like Rust, amirite?
Partly; OCaml does not, in the general case, generate code for a function for each boxed data type it is called with, for example. This, and the fact that the compiler does not optimize extensively, makes for fast compilation. The code still runs fast, especially for a language with gc.
OCaml has other serious issues.
What are those issues, if you don't mind me asking? Don't see much OCaml discussion here so I'll take interesting discussions where I can get them.
My biggest gripes:
* Windows support is mediocre due to decades of not supporting it at all.
* OPAM is a nightmare. Surprisingly buggy and extremely confusing. We're not talking Pip levels of badness but it's nowhere near as good as Rust, Zig or Go's equivalents.
* A silly obsession with linked lists. Ok I understand why but it's still annoying.
* Ocamlfmt thinks it is writing an essay, and generally makes things less readable IMO.
* The syntax is not easy to read. They threw away all the useful punctuation that help you visually parse code.
* Tiny community.
* Very spartan documentation. Examples are very rare.
* Global type inference is definitely worse than Rust's local approach because it makes errors much worse, and makes the code harder to understand.
* Native int type is 63 bits.
I haven't even done much OCaml but it's definitely got enough issues that I strongly prefer Rust. Just the community size is reason enough really.
That said, it's still way better than Python, Ruby, PHP, Java, JavaScript and Perl. Those are kind of the Z-tier languages though so I guess that's not saying much.
If it was a choice between OCaml and Go, Swift, C#, Dart... then it wouldn't be a slam dunk either way. Unless you wanted Windows support and then OCaml is a crazy choice.
I used OCaml extensively for a few years, around the time of OCaml 3 and OCaml 4, and I can add a few cents to this discussion.
Some of the points listed here can be considered a matter of taste or opinion, some are indeed pain points, and some are implementation details.
OCaml as a whole is hard to directly compare with most other languages you mentioned above as "better" or "worse". It both suffers and benefits from being an academic/research project not directly in control of a larger corporation.
As a language, IMHO, it is miles ahead of mostly all the languages mentioned above. It recently adopted a novel mechanism for modeling concurrency called algebraic effects, together with state-of-art multi-core support. This not only abstracts away several features that are usually hardcoded on most languages but puts it on another level as a language and abstraction capability. There are other toy languages that implement similar mechanisms or part of this, but none with the adoption level of OCaml.
However, since it does not have the same amount of resources and adoption, progress sometimes is slower that one would expect. Documentation can be sparse, community is smaller, etc.
Regarding OCaml on Windows, I myself used it exactly 20 years ago. It not only has one implementation, but three. There are some tradeoffs and support is not at the same level as Linux but it's still there, and I wouldn't call it mediocre:
https://github.com/ocaml/ocaml/blob/trunk/README.win32.adoc
https://docs.google.com/document/d/1-aTygzDsxy4mnqvSKEVhifA1...
You might find it harder to find libraries, for sure. I have not checked the situation recently, though given the smaller community that is likely still the case.
As a tongue-in-cheek comment, I could definitely say "OCaml is certainly not a good language - not as bad as most of all the others though".
I can certainly see how those can be problematic. Thanks for taking the time to elaborate!
Maybe it’s not a fair judgement because I just looked at the docs, but I didn’t like the syntax on first looking at it.
> We actually had a recent Cloudflare outage caused by a crash on unwrap() function
> 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.
> Arc<Mutex<Box<T>>> is complex
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.
Probably if you use a lot of Arc<Mutex<Box<T>>> languages with proper runtime (like Go or Java) are gonna be more performant, in the end they are built with those abstractions in mind. So the question isn’t only how much the nature of the problem it is, but also how common the problem is, and is rust a correct way to solve this problem.
If you use a lot of Arc<Mutex<Box<T>>> you you probably just learn to use Rust properly and just use Arc<Mutex<T>> instead because it pretty much never makes sense to have a Box inside an Arc...
I say that as someone that thinks Rust's learning curve is the main reason it rarely makes economic sense to use it.
This is either performance art or rage bait. The opinions here are so wild. There are so many claims here that are wrong and just strange, it is hard to know where to start.
Seeing this comment from Kent Overstreet was hysterical: https://news.ycombinator.com/item?id=46029555. He's not even criticizing Rust, nor is he the author, but still...
But yes, this sure is a nice and sane thread.
The biggest value of Rust is to avoid heisenbug https://en.wikipedia.org/wiki/Heisenbug
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.
> The article has some valid points but is full of ragebait exaggeration.
Given that Rust doesn’t always have critiques that are backed with evidence, this wasn’t bad.
People can use C now that LLMs make it easier, so Rust is no longer needed in many ways.
You are joking, right? Writing c with llm‘s… what can go wrong?!
> Given that Rust doesn’t always have critiques that are backed with evidence, this wasn’t bad.
What evidence?
The author would probably find joy in using Zig.
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++.
> 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++.
There is always a trade-off. You really cannot provide enough information for the compiler without the current signatures. There is a certain point where you cannot compress the information without losing some features.
It's always an option to create type aliases, but there's a bit of "robbing Peter to pay Paul" happening when you do that.
You make the signature shorter but also take away the ability for the programmer to quickly understand what code is doing.
I fully believe you, I don't know what the solution would be either.
> telling a victim “but the memory was not corrupted in the crash” is a weak consolation. We actually had a recent Cloudflare outage caused by a crash on unwrap() function. It’s probably the strongest point of my whining: Rust is memory safe and unreliable. The price of memory safety was reliability
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.
Why did they name the crash() function "unwrap()" ? Feels weird to me ...
> Why did they name the crash() function "unwrap()" ?
Because unwrap() is not guaranteed to cause a crash? panic!() is there if you actually want to guarantee a panic.
First, he didn't call the "crash()" function, he called the "unwrap()" function. The fact that they decided to call the crash function "unwrap()" is not the OP's fault, it's the language authors' fault.
Second, you totally missed the OP's point about reliability. If one has to choose between UB and an immediate halt, those are pretty sucky options. And the OP is 100% right about Rust crashing all the time. Nothing insulting about that, just a fact.
You get to choose between UB, a crash, or handling the error — same as most other languages.
It’s not a reliability issue of the language if as an author of software you choose to crash in your failure handling cases. Claiming otherwise is either disingenuous or a failure to understand what actually happened.
No, it's not the "same as most other languages". C and C++ are actually the only mainstream languages that suffer from UB to this extent.
The fact that, in practice, with Rust you get a crash instead of UB is 100% a reliability issue with the language. The crashes are inbuilt. And blaming the crash on the author, saying they "chose to crash", is exactly the same as blaming UB on the author of C code, saying they "chose to double-free".
> The fact that, in practice, with Rust you get a crash instead of UB is 100% a reliability issue with the language. The crashes are inbuilt.
This is totally false. It's not in the least hard to avoid crashing.
The fact that Cloudflare chose to handle a result with the "panic if this result is an error" function is 100% on them, not on the language. Blaming the language is like claiming that any language which has assert is a problem because the assert can crash your program. Yes, that's what it's there for, so don't use it if that isn't what you want.And don't give me the "the method name isn't obvious enough" argument you used elsewhere. That holds no water. It's basic Rust knowledge to know that "unwrap" will panic if the value is an error (or None if it's optional). If the engineers writing the code didn't know that, then the problem is they didn't bother to learn how their tools work, which again is not the language's fault.
What UB? This has nothing to do with UB; it'd be well-defined in any language. It's equivalent to this python snippet:
Did Python do something wrong by letting users call `sys.exit`? No. This is a deliberate crash. Under other circumstances, crashing might have been a valid strategy, but here it turned out to be a bad choice, since Cloudflare's infrastructure was restarting the service with the same bad config every time.Sys exit does not crash. It raises a SystemExit exception, which can be caught on any layer above it. Given that python uses exceptions for trivial things like loop termination this can be considered normal flow control.
Yeah, and in Rust you can catch the panic from `unwrap()` with panic::catch_unwind. You just don't, for the same reason you don't catch SystemExits. If a SystemExit is being thrown, it's because you want to crash; if you don't wan to crash, don't throw a SystemExit.
And, by default, panicking in Rust also doesn't crash, it begins a stack unwind which can be caught on any layer above it with catch_unwind.
If I could choose between UB and a crash I will chose the crash every time. The sooner the better, preferably in test. And that's where CF's real failure was.
You don't have to call unwrap()...Rust provides alternatives, which are very prominent.
Mutable shared state is a feature, not a bug.
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.
Idk, it's a general rule of thumb that the more mutable shared state an algorithm has, the worse it scales. So if you're trying to scale something to be concurrent, mutable shared state is an antipattern.
At scale, algorithms are commonly limited by memory bandwidth, not concurrency. Most code can be engineered with enough cheap concurrency to efficiently saturate memory bandwidth.
This explains why massively parallel HPC codes are mostly minimal mutable state designs despite seemingly poor theoretical properties for parallelism. Real world performance and scalability is dictated by minimization of memory copies and maximization of cache disjointness.
It's certainly true that some things are limited by memory bandwidth. But it's also common to be limited in other ways.
as noted someone else, it is lock contention that doesn't scale, not mutable shared state. lock-free data structures, patterns like RCU ... in many cases these will scale entirely appropriately to the case at hand. A lot of situations that require high-scale mutable shared state have an inherent asymmetry to the data usage (e.g. one consumer, many writers; many consumers; one writer) that nearly always allow a better pattern than "wrap it in a mutex".
Mutable shared state is literally the nature of contention. It's true that locking is the mediocre default, but "avoid locks" is not a silver bullet. Alternatives have their own tradeoffs. If you "carefully design" a solution, it's probably because you're not just using an alternative but actually taking care to optimize, and because you have a specific use case (which you described).
No, it's the mutable shared state that is the problem. Lock contention is just downstream of the same problems as any other mutable shared state.
> patterns like RCU
RCU isn't mutable shared state! It's sharing immutable state! That's the whole paradigm.
What do you think the "update" part of RCU actually does?
RCU publishes a new pointer after Copying and Updating the copied state. It's not mutating in-place. You don't use it for frequent updates.
https://en.wikipedia.org/wiki/Read-copy-update#Name_and_over...
You may not use it for frequent updates; we do.
There is state.
It is shared state.
It is mutable state.
There are readers, who can see the shared state.
There are writers, who copy it, update it and push it back so that the new state is visible to everyone else.
I have no idea what your definition of mutable shared state might be if that doesn't fit it.
Nothing is preventing you from writing or using lock-free data structures or other solutions in Rust.
It's lock contention that slows things down more than anything.
But it's really an 'it depends' situation.
The fastest algorithms will smartly divide up the shared data being operated on in a way that avoids contention. For example, if working on a matrix, then dividing that matrix into tiles that are concurrently processed.
> It's lock contention that slows things down more than anything.
It's all flavors of the same thing. Lock contention is slow because sharing mutable state between cores is slow. It's all ~MOESI.
> The fastest algorithms will smartly divide up the shared data being operated on in a way that avoids contention. For example, if working on a matrix, then dividing that matrix into tiles that are concurrently processed.
Yes. Aka shared nothing, or read-only shared state.
> Rust is memory safe and unreliable. The price of memory safety was reliability
Uptime isn't reliability; it's producing predictable behavior. Allowing indeterminate ("malfunctioning") behavior is the opposite of reliability.
> T, T&, T*, std::optional, std::unique_ptr to describe similar things, each broken in its own way
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.
> No matter what language you use, most of the code running between what you wrote and the hardware will be written in C.
The goal of changing that is a big part of why there’s so much discussion about Rust.
> Your choice for the 1% on top is not very consequential. There is still a huge attack surface area no matter what.
For an internet-exposed service, the 1% that implements that service is important. Most of the rest of that attack surface is only accessible if an attacker gets past that first layer.
I was waiting for the part where author advocates for what they like but no it’s just a rant
Spending out something better isn’t easy. As an applications developer I want to ask “Why don’t you just use Java/C#?” and I’d go so far to say that the software reuse revolution behind Java was not OO or it’s particular approach to OO but rather the garbage collector.
That is, building applications out of premade parts is a struggle in C or C++ or rust because memory management is part of the API. C devs would be very concerned about having control of memory allocation and would like to have the choice of reusing a buffer from the application in the library or have the library allocate into an arena managed by the application, etc. It’s complicated enough that libraries can’t reasonably support every scenario application developers would like and ultimately tough because to free something the application has to know if the library is done with it or the library has to know if the application is done with it…. However, the garbage collector knows!. In the end there are a lot of libraries you can’t really write for C or if you can write them you have to write them assuming the application allocates or a certain way or you lose the benefit of being in control of allocation that C allegedly gives you.
On the flip side I think C is too high level in some cases, for instance you come to think the gymnastics involved in written embedded C or device drivers are normal but there are quite a few things that are a little bit cleaner in assembly language and I write things for AVR-8 that are rather small but it drives me nuts that C is moving the stack pointer around and following calling conventions that are not at all necessary for these particular programs.
I had friends who worked in the IBM Mainframe world where it is still common for applications to have bits written in assembly because of efficiency or to get finer control than you can get with COBOL. Part of the COBOL puzzle is that you have to be a Macro Assembler programmer to work on that stuff and you can’t just port it to GNU COBOL on Linux without also porting the assembly!
We’re still living in a multi-architecture world so the interesting idea of trying to make it easier to write assembly (imagine a super macro assembler with an integrated theorem prover) is a non-starter. Let x86 founder for a decade and if RISC-V makes no progress that picture could be different in a few years.
over the past decade i've spent alot of time compiling rust code for arm6 / arm7 cpu's, which is a fancy way of saying that in my free time i have spent alot of time running `cargo build` on a variety of raspberry pi's.
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
What a waste of time article. There is plenty of debunking of the points already so I won't repeat them.
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".
The blogs about page is fun:
> 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.
There is a fundamental trade off between (1) Memory Safety (2) Zero cost abstraction/Performance (3) Ease of use
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.
"they only corrupt user data and act sporadically"
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.
That was quite literally the author's point.
You cannot go along like “I’m writing a cold path high-level code, I don’t need performance, I don’t need to go deeper into lifetime handling, I just want to write a high level logic”. You will be forced into the low level nuances every time you write a single line of Rust. There is no garbage collector for Rust and will never be — you will have to semi-manually pack all your data into a tree of ownership. You have to be fluent in ownership, borrowing, traits to write just a few lines of code.
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.
the issues with Crystal, nim, zig, is that they have zero changes to be bigger.
crtystal and nim, probably not.
Zig... is surprisngly used a lot given how rough the state of the language is. It makes me think that if it ever reaches v1.0, it has a very good chance of being at least a "Kotlin", probably a "elixir"/"haskell", and a decent enough shot of "typescript".
I think people are missing the main point. The real issue with Rust is that it is a designed language which is really tuned and optimized for a specific use case. And for that specific usage, it is really, really good. But even so, it requires a lot more up-front work, due to the limitations and restrictions it imposes.
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.
> Node.js and Go are considered practically safe language
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
Node.js and Go are both memory safe, as are Python, Ruby, and Java. "Memory safe" is a term of art referring to susceptibility to memory corruption vulnerabilities in code written by an ordinary practitioner of the language. Almost invariably, attempts to show languages like Go and Python as memory-unsafe involve a programmer deliberately working to defeat the language. But you can do that in any language, including Rust.
There are essentially just two mainstream memory-unsafe languages: C and C++.
It's easy to cause memory corruption with Go while building a concurrent system, you don't need to learn anything about "defeating the language".
I agree, and I personally wouldn't call golang memory safe for that reason. Thomas's semi-definition includes the word "vulnerability", which narrows the scope so much that golang fits under the bar, since the common data race that causes memory corruption hasn't been shown to be exploitable without being contrived.
My personal definition of memory safety for a language like golang would specify that you can't cause this sort of memory corruption without an explicit call to unsafe, but there's no real definition to fall back on.
The same thing happens any time a message board confronts a professional term of art. The same thing happened with "zero trust", where you'd have long wooly debates about what was meant by "trust", but really the term just meant not having a conventional perimeter network architecture. Sorry, but the term as used in industry, by the ISRG, and in government guidance refers specifically to vulnerabilities.
"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.
The amount of Rust code using unsafe is a major issues for a language build around safety. And yes, the same argument can also be made about Go having a unsafe keyword.
The fact that there exist crates to detected the usage of unsafe in dependencies, shows that its a rather liberal used keyword. Geiger comes to mind.
Unsafe in a language like Go is very rare, mostly because people do not program at such low system level to get the max performance out of it.
Rust code with unsafe: 1.7M Go code with unsafe: 400k
and for comparison, Go has about 2.3x the amount of repo's. So Rust has about a 10x more usage of the unsafe keyword.
While unsafe is always a risk in Rust, measuring the risk is not nearly as straightforward as counting lines of code. In particular, Rust focuses on encapsulating unsafe code behind safe wrappers that prevent misuse, so the better measure is determining which crates don't do this, and to what extent they can be easily patched to do so.
It's got really not much at all to do with `unsafe`.
[flagged]
I didn't downvote you and couldn't have (you were replying to me).
Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
https://news.ycombinator.com/newsguidelines.html
[flagged]
Having run into memory issues in go but not (yet) in rust I would tend to disagree with this. It's really not hard or esoteric to run into it in go.
"running into memory issues" doesn't relate to memory safety as a property
I thought it was clear "Running into memory issues" meant memory safety violations as that was what we we were talking about. I guess not...
> "there is just no perfect correctness possible in the Turing machine model"
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.
Theorem prover ideas have an impact on Java, Rust and a lot of languages —- it really would be great to see something that accomplishes even more…. Would be nice if you could have a program that lives side by side with a correctness proof.
> if you're program is anywhere near undecidability, it has no business being in the kernel.
who the hell cares just about "the kernel" (whatever kernel that is) ? I write native desktop applications and they are completely unverifiable.
So, Ada?
The post describes very clearly why you should choose Go if this is where you're at.
I was a Rust programmer, for 3 years. Did web backend, kernel programming, network security...
Then I discovered that C++ has a very cool feature that Rust doesn't have: jobs.
Now, I no longer search for Rust positions.
Thanks for the laugh!
I can accept compilation being slow, slower than C++, but do large projects require >32GB memory, for example the case of LLVM, Chromium, or Envoy?
Had to buy a new laptop because of this.
> Unfortunately, it’s impossible to make Rust compile fast. The problem is inherent to all similar generics-heavy languages, like Haskell.
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...
I am biased, so keep that in mind.
> 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.
> 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 — that’s why I’m telling the language designers went overboard.
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.
I'm annoyed that this submission's title was changed. This was first submitted with the original title, "Rust is a disappointment," and got flagged. It looks like it's been unflagged and the title has been changed.
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?
Language wars are an endemic pathogen on HN and any steps we take to suppress are probably for the good.
As long as the steps are symetric among languages, I'm fine.
But that's rarely the case with flagging. I'd say impossible to enforce even.
> Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing
Yeah, just another data leak, no biggie.
What's a bit of arbitrary code execution between friends?
Regarding slow compilation...
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).
My understanding is Rust compiles each crate in the same way C++ compiles each .cpp file, so if you stick everything in a single crate you get horrible compile times.
This does seem like a poor design decision by Rust to me, forcing people to break things into arbitrary crates just to get reasonable compile times.
It also seems like a disaster for incremental compilation.
> This does seem like a poor design decision by Rust to me, forcing people to break things into arbitrary crates just to get reasonable compile times.
Not necessarily, since codegen units can introduce intra-crate parallelism during compilation.
But in any case, as with basically everything there are tradeoffs involved in choosing compilation unit size. Making your compilation unit crate-sized also means that you have some more flexibility in your code organization (e.g., stuff can mutually depend on each other, which is itself potentially useful and/or harmful) and you don't run into other potential issues like the orphan rule. There are also potential impacts on optimization, though LTO muddy the picture. Codegen units are just the cherry on top.
There's almost certainly other things I'm forgetting and/or not knowledgeable about as well.
Am I understanding that bykozy is claiming that "Rust is memory safe and unreliable" because Cloudflare crashed due to an unhandled exception??
This is the quality of discourse I expect at this point from anti-Rust folks, yes.
Use D.
I mean there's nothing better than Rust, just talk about what in Rust is annoying instead of saying that
Unless I need close to 100% memory safety with no compromise in performance I'd rather write Zig, Odin or Go.
Zig and Odin are much more enjoyable to write and provide enough safety for a lot of applications, and Go gets you 90% of the performance of Rust without the complexity.
>Unless I need close to 100% memory safety
If you need that, you go Ada.
Rust is practically the same as Zig, when compared to Ada.
I swear there are people who take a massive amount of pride in using languages or technology that are obscure. That thing use to be Rust, but now that it's become fairly mainstream they have to find something new to move to.
I wonder how long it will be before we start seeing "Ada is the new Rust" YouTube videos.
I don’t think i’ll ever understand the compile time argument https://xkcd.com/303/
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?
> Seemingly, there is an assumption that software written in Rust is inherently better
Yes. Both Rust and its standard library have features that make programs be less likely to have problems.
> than any other
No. It's just better than the languages that are very popular right now.
> or that if something is written in Rust, it cannot have any errors.
No. How people keep jumping from "better" to "absolutely 100% infallible" is beyond me. Nobody is claiming this.
> But why fix programs that are already memory safe?
Because:
1. Programs that are already memory safe still need to be improved, and those improvements are really dangerous in a dangerous language
2. Things like https://news.ycombinator.com/item?id=46013579
I think we’ve officially reached the inflection point where the Rust haters have become more annoying than the Rust evangelists. Maybe in a couple years we will finally be able to stop writing blog post about it.
“Summary:
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 — this fact alone makes Rust a viable tool, just because you can pick it from the shelf and employ as-is. This blog was generated with Zola, written in Rust — I did not have to write a single line of Rust code to use it. And the Rust is a good fit for Zola SSG because of its non-interactive nature with one-way flow of immutable data. Just, please, don’t run around screaming “we should all switch our development to Rust because it’s the best programming language”.”
Is this what makes someone a Rust hater?
Literally hates on Rust for the whole article except the final summary.
Man, I explained it in the first sentence of the article — it's not bad, it's much worse than it could have been. The main body of the article is not hate — it's plain facts. Everybody working on a significant Rust codebase agrees that Rust compilation takes eternity. Complexity? I know people that like complexity, they would say "that's a great language because of how hard it is to write a program in it!" — complexity would feel like a praise for them. Shared state? "Just don't use it, you are doing it wrong". That's is, where is the hatred?
Subjectiviy (eternity, complex, etc) is never factual. Your post has facts, it does, but it still sounds a lot like hate.
> The main body of the article is not hate — it's plain facts. Everybody working on a significant Rust codebase agrees ...
Lol. Its not facts. Its a description of frustrating things you've experienced working with rust, dressed up as "deep truths about the language". You don't speak for the rust community. This article would be much more interesting if you just talked about your own experience without pretending your issues are universal.
Re: compilation time, in the 2024 state of rust survey 25% of rust developers said slow builds was a big problem. And thats a lot of people! But 19% of people said its not a problem at all for them. Its certainly not "everyone".
https://blog.rust-lang.org/2025/02/13/2024-State-Of-Rust-Sur...
I suspect if you keep using rust, the things that annoy you about the language will change a lot over time. Some things will stop bothering you, and some things will start bothering you a lot more! (Like IMO Rc/Box/etc isn't a big deal. Once you learn to structure your code in a rusty way, you almost never need that stuff.)
I really like rust now. But I found learning rust to be incredibly painful. I get why you're struggling with it. But please don't confuse your struggle for universal truths about rust. You're only one person.
It seems pretty clear from the article as a whole.
> Rust haters have become more annoying than the Rust evangelists
I disagree. There's a long road till that inflection point for me.
At least the Rust evangelist build shit.
People who get shit done are too busy to evangelize.
Speaking of, maybe I started paying attention at the wrong time, but I could swear I've seen like 10x more post/comment volume whining about how annoying the "Rust evangelism strike force" supposedly is than actual excessive Rust evangelism
Absolutely not. Rust lovers are still incessant as they’ve ever been. More Rust haters is a good thing.
Can you give some examples? C/C++ devs seem to be very upset about rust content. Where all these annoying articles claiming we should rewrite everything in rust? They must be all over the place given how much C/C++ devs are upset. But I don't think I've read any?
There was that article from the android team about how rust improved their development workflow[1]. Is that what you're talking about? Was that article emotionally upsetting? Do you wish it wasn't written? What in particular is upsetting? Do you want people to stop writing technical articles to protect your feelings?
[1] https://news.ycombinator.com/item?id=45918616
I haven’t seen a positive Rust article hit HN in over a year. Seems the zeitgeist has turned against it. All it took was the US government giving the thumbs up I guess.
On the other hand, lets face it: most of the time security in IT systems is the least priority. I mean after shipping fast, iterate fast, better performance, compatibility, architecture soundness (whatever it is), convenient tests, docs with UML diagram, well-designed interface — and somewhere in a distant drawer on the bottom you may find a note about security issues. It's often times people talk about importance of security after it destroyed the whole business.
We need more of the security. We probably don't need the Rust though.
security incident destroying a business is so rare and penalties for security breaches are non-existent and hence while everyone talks “security is important” it really isn’t all that important - in vast majority of the situations. I mean, fucking experian, the company whose sole purpose for existence is collecting and keeping data on everyone safe leaked everyone’s data and everyone was like “oh ok, thats cool, carry on…”
>We probably don't need the Rust though.
Uhm, I would have picked Rust just for shipping fast, iterating fast, better performance and compatibility. The security is a bonus that comes along for the ride. You probably haven't had the displeasure to work with C++ in combination with ROS. That experience really soured me on C++.
We really just need official/honest guidance on Rust for what works and what doesn't. The classic example is the dodging around cyclic datastructures.
Tl;DR Rust doesn't support any form of cyclic datastructure without indirection or unsafe. The indirection tooling is weak, and most real examples simply switch to unsafe rust. Unsafe rust is completely fine if you know what you are doing with memory, and is ok to use in these situations.
There are a few other gotchas that we just need to be clear about, some of these gotchas are limiting for developing higher level software and some are not e.g. String handling. If you are comfortable with unsafe, the rust toolchain is vastly superior to C/C++ development making it as close to an ideal replacement as we are likely to get.
A couple years ago I implemented a btree (technically order statistic tree) in a couple thousand lines of unsafe rust for a project. I wrote it more or less how I'd do it in C. Each internal node and leaf node was a separate heap allocation and internal nodes had an array of child pointers. It was surprisingly hard to program up. And complicated!
In my opinion, unsafe rust code is worse to use than C because rust is missing the arrow operator. And rust still requires strict aliasing to be followed even in unsafe code. This makes complex unsafe code very hard to implement correctly. Like, it’s easy for something to look right and work correctly but for MIR to still find subtle issues.
Eventually I rewrote my btree on top of Vecs. My node & leaf pointers are now array indices. The result? There is no longer any unsafe code. The code has become significantly simpler and it now runs ~10% faster than it did before, which is shocking to me. I guess bounds checks are cheaper than memory fragmentation on modern computers.
I have so many thoughts having done that. First, I think this is actually the right way to write rust. Yes, manually keeping track of which array slots are in use is inconvenient. But unsafe & pointers are also quite inconvenient in rust. Programming like this makes use after free bugs possible to write. But it’s still memory safe by rust’s definition. It’s impossible to get arbitrary heap corruption because there are no raw pointers. And the indexes are bounds checked.
I also don’t think the resulting code is any worse than the equivalent C++. Everyone talks about memory safety but IMO rust’s best features are enums, traits, cargo, match expressions and so on. Even when you do a run around the borrow checker, it’s these features which make me keep coming back to rust.
I agree better guidance would be nice, but so many words have been spilled on rust already. Would you find content talking about subtle stuff like this? Sometimes the only way to learn is by trying stuff out.
>Eventually I rewrote my btree on top of Vecs. My node & leaf pointers are now array indices. The result? There is no longer any unsafe code. The code has become significantly simpler and it now runs ~10% faster than it did before, which is shocking to me. I guess bounds checks are cheaper than memory fragmentation on modern computers.
Optimizations are very complex and potentially fragile in Rust, LLVM has to sort through tons of generated IR, so it might be just that native Rust structures are optimized better for compilation. Particulary, Rust is able to optimize out some bound checks.
Do note that binary trees are mostly an obsolete legacy today — they are way too cache-unfriendly. I mean you could have written similar code in C++ using std::vector or std::dequeue and get the bounds checking too.
>Everyone talks about memory safety but IMO rust’s best features are enums, traits, cargo, match expressions and so on
C++20 with concepts mostly reproduce the traits. C++17 with std::variants emulate enum/tagged union. Match is unmatched by C++, that's true.
Cargo is good for as long as there are few packages in there. Large projects already suffer from five versions of serde in one build and dependencies on FFI-connected libs that cargo itself cannot build. I mean look at the NPM nightmare — and they've mostly dodged FFI-s.
> Do note that binary trees are mostly an obsolete legacy today — they are way too cache-unfriendly. I mean you could have written similar code in C++ using std::vector or std::dequeue and get the bounds checking too.
As a sibling comment said, its a b-tree not a binary tree. B-trees are - as far as I know - the fastest data structure on modern computers for the class of problems they solve.
And yes, I think if I ever go back to C/C++ I'll try this approach out. It might also work great in GC languages like JS/TS/C#/Go because there's fewer pointers to keep track of.
> Cargo is good for as long as there are few packages in there. Large projects already suffer from five versions of serde in one build and dependencies on FFI-connected libs that cargo itself cannot build. I mean look at the NPM nightmare — and they've mostly dodged FFI-s.
I haven't run into the "five versions of serde" problem, but I can easily imagine it. I've lived NPM nightmares more times than I can count. But I'd still prefer that to all the problems you get from CMake, autotools and Makefiles. At this rate we're going to get self driving cars before we have a single sane build system for C.
> Particulary, Rust is able to optimize out some bound checks.
It doesn’t optimise out the bounds checks. I checked the assembly.
Bounds checks in rust always look so ugly if you look at the assembly output because there’s all this panic string building and whatnot. But in practice, I think it’s just that modern CPUs have excellent branch prediction. A branch that follows the same path 100% of the time is cheap. Especially when it has UNLIKELY() annotation hints in the code. This is the case for bounds checks. They just don’t really show up in benchmarks as much you’d think.
> Do note that binary trees are mostly an obsolete legacy today — they are way too cache-unfriendly
BTree is not Binary Tree. It's B-Tree and is cache-friendly
> C++20 with concepts mostly reproduce the traits.
C++20 concepts are not the same as traits. Concepts are structural and awkward to use compared to Traits which are nominal. There are other important differences, too.
>Do note that binary trees are mostly an obsolete legacy today — they are way too cache-unfriendly. I mean you could have written similar code in C++ using std::vector or std::dequeue and get the bounds checking too.
This is simply not true, it's an ongoing thorn of mine that the Rust community seems to decide that anything which cannot be programmed in rust is obsolete legacy. This is a silly stance which is harming adoption.
I for one have coded dozens or even hundreds of tree structures. My most recent tree was a hierarchical context management system for an LLM agent!
> it's an ongoing thorn of mine that the Rust community seems to decide that anything which cannot be programmed in rust is obsolete legacy.
Nobody is arguing that you can't program a binary tree or b-tree in rust.
I think its true that binary trees almost always perform worse than b-trees in programming in general. But that isn't a comment about rust. Its a comment about modern CPU memory & cache behavior.
The person you're replying to is the author of the blog post, which I would not accuse of being a Rust proponent.
We are nowhere near that inflection point!
Not to worry, another tech thing will be along shortly to fill the hype/hate cycle with its own drivel.
Zig currently sits in the hype cycle like Rust/Ruby/Lisp/etc once did here. Eventually something will come along and Zig will be in the hate cycle.
In reality none of these things need the religious wars that seem to go back and forth. It's just an incredibly unfortunate and annoying aspect of how programmer-centric communities tend to go.
The objective rate of improvement in programming languages has been slower than virtually every other field. Computers have gotten millions of times faster since the advent of C, but programming languages have arguably gotten maybe 10% better in that span.
Unfortunately there are topics that should stop long ago but people still rave about those: ORMs, OOP, Git, JavaScript bloat, Linux vs Windows.
Somehow there are always fresh people who think someone cares or that somehow those are important discussions.
>ORMs, OOP, Git, JavaScript bloat, Linux vs Windows
ORM and OOP whine is niche, agreed. Linux vs Windows is irrelevant because windows runs linux nowadays — I don't think I've read a single article about it.
Git? Okay, mostly circumvented by solutions that don't carry any implementation from the original Git, but have "git" in the product name.
Javascript bloat? I'm pretty sure that's still a hot topic. I don't remember it being solved, do you? Like if I open website and it greets me with a window suggesting to apply cookie policies for 300 (three hundred) trackers on the website — isn't it worth talking about?
ok, I'll bite.
What's the git product that only carries the name?
>Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times.
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.
> Refactor your build.
People do this, and at best it works for some people. This kind of messaging towards people who bring up a valid criticism of Rust does not help.
Although naively factored builds can be slow on rust, I firmly believe that most folks complaining about this problem have not taken the time to learn how to do this and their builds could be perhaps 10x faster. Bringing this up an important counter-point that all too frequently is ignored or met with hostility, as this replier has done.
I do not understand how you justify your claims. Should I link any number of instances where Rust team members admit to compile times being a major issue, one which prompts significant effort to improve? Perhaps you are right about 10x speedups, but then that clearly isn't enough, reading the room.
I also do not understand how you see hostility in my comment. For one thing, I did not downvote you. Rather, your original comment is dismissive, even if the article it replies to is dubious. For another, it would also be trivial to see that I am both highly supportive and informed about Rust. Your comments simply do not help, certainly not with the common perception of Rust fans as zealots.
Don’t know what to tell you. Just trying to keep things real in response to a highly ungrounded post. The issues with compilation times are as severe an issue because of the reason I mentioned — folks don’t like to think about how they factor their build. So some members of the core team are sympathetic to that — and for good reason.
But the virtues of shifting context to the build and refactoring it is rarely discussed and would alleviate many individuals problems. I see it rarely mentioned, just “rust is slow to compile” so I really do feel it should be discussed more; even if I could have perhaps mentioned it in a way you (and others?) would have experienced as less dismissive.
I can't speak for everyone, or even the majority, but I know that oftentimes large projects focus on build times, undergoing refactorings as you describe, and their compile times are still high. To make up some numbers, maybe the fraction of projects that have unacceptable compile times could be reduced from 80% to 40% (at what effort?), but that 40% remainder probably includes many large, popular crates.
[flagged]
This reads nothing at all like AI text. It's full of grammatical errors and clipped sentences. It's written in the style of a message board post.
Why do you think that?
Because it follows same structure as the one used by LLM-s. At least there is a reason to think so — before you've tried to actually read the article and realize LLM-s just don't write text like this... yet. Of course, this structure is also the one used by scientific articles, which I read a lot too, so I'm really inclined to follow this style. "Has the form of scientific article but statements are not precise = AI slop" — that's the implication.
Funny fact: one of the reasons Qwen suggested my article is LLM-generated is because it considered link as impossible. I was so gaslit I opened the article and clicked the link. And it worked. Mic drop.
The ragebait part is because it feels more provocative than sincere.
Some examples from the introduction:
> Its compilation is slow. I mean SLOW. Slower than C++. I know over years Rust became several times faster, but objectively we need it to be two orders of magnitude faster, not just two times.
I've done significant C++ and Rust and Rust compiles WAY faster than C++ for day-to-day incremental compilation. C++ suffers from the header inclusion problem and modules may as well not exist because you can't practically use them.
> Arc<Mutex<Box<T>>>
This is intentionally over complicated, there is no reason for the Box to be there.
> You cannot get 99.999% reliability with Rust — it crashes all the time.
What does this even mean?
>I've done significant C++ and Rust and Rust compiles WAY faster than C++ for day-to-day incremental compilation. C++ suffers from the header inclusion problem and modules may as well not exist because you can't practically use them.
It really depends on what you are compiling. I did lots of C/C++ that compiled 50k lines of code in 10 seconds FROM SCRATCH — I doubt you can do it in Rust. To be fair, headers in that project were somewhat optimized for compilation speed (not "hardcore", but "somewhat"). People forgot how fast C/C++ compilation can be without 10 Boost includes in each module.
>This is intentionally over complicated, there is no reason for the Box to be there.
Arc<RwLock<Option<T>>> — sounds good now? Don't get me wrong — C++ can be just as horrible, but Rust made it a rule, you can only write your program like this.
>What does this even mean?
I've already answered above, but I can repeat: there are runtime models that allow crash and recover, there are models that crash and limp. In Rust there is only one model of crash: you just crash.
> I doubt you can do it in Rust.
You absolutely can. You'll need to pay attention to how things are structured and not all codebases will be equally amenable to such techniques, but those are shared characteristics with C++.
As you said, "It really depends on what you are compiling."
> In Rust there is only one model of crash: you just crash.
Hardly. Why else would catch_unwind exist?
> It really depends on what you are compiling. I did lots of C/C++ that compiled 50k lines of code in 10 seconds FROM SCRATCH — I doubt you can do it in Rust. To be fair, headers in that project were somewhat optimized for compilation speed (not "hardcore", but "somewhat"). People forgot how fast C/C++ compilation can be without 10 Boost includes in each module.
Incremental compiles in Rust are very fast because it has an actual module system instead of textual include. I don't care much how long from scratch compiles take, but even there my experience is Rust is faster than C++.
> Arc<RwLock<Option<T>>> — sounds good now? Don't get me wrong — C++ can be just as horrible, but Rust made it a rule, you can only write your program like this.
I'm not sure what non-garbage collected language would be better here. C++ would be about the same. C would be far far worse as it has no templates. Garbage collection would allow you to omit the Arc, and a language like Java where nearly _everything_ is optional would allow you to omit the Option, but I don't think many people would make this trade.
> I've already answered above, but I can repeat: there are runtime models that allow crash and recover, there are models that crash and limp. In Rust there is only one model of crash: you just crash.
You haven't defined what "crash" means. Rust uses a Result types for error flow and you have just as much control over recovery as any other language. If you are talking about panic, well yeah, that's like calling abort() in C, except it allows more fine grained error recovery with catch_unwind instead of a global SIGABRT handler or w/e for your OS.
I don’t disagree with the rage bait assessment.
lists, em dashes, headings and typical length of LLM response.
Yeah, the article was written in Markdown, LLM-s employ markdown formatting too. It's not a typical length of LLM response — it's approx 1.5-2.0 times longer than a typical long LLM response. Not easily noticable to a human being though, indeed.
I disagreed with your article, but this critique of it is just goofy. I also write in Markdown, use lists where appropriate, and — gasp! — write em dashes where appropriate.
You think an AI wrote "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 — this fact alone makes Rust a viable tool"? No it didn't.
I 100% think LLMs were involved in its production, just not written wholesale.
It's 200% LLM used in production — like 10 hours of dialogs right before writing the article. I had much more hours of coversations with Rust fanboys and it was mostly a waste of time, they just would not try to negotiate on Rust's weak points. I would definitely not be able to write the article with only human support — it's really sad to conclude that LLM-s are much better assistants because they are neutral and objective.
Were any parts copy pasted from LLM output (and possible changed after)?
Why would I do this and why do you think I did? Or do you feel like my english is so bad I'm probably writing ransom note out of pieces of LLM output? I can ensure you I'm good enough at typing and talking in english to not require copy-pasting. Do you have any quotes from the article that you feel like were copy-pasted from LLM?
soon we ll hafta rite lyk dis and maybe தேவையே இல்லாம include other languages in the text, just so people won't automatically say it's AI written.
> You have to be fluent in ownership, borrowing, traits to write just a few lines of code.
> Rust sacrificed sanity and practicality for memory safety
skill issue
Totally wrong.
> 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.
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.
>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.
I have a working theory that the classic programming is basically dying out: https://bykozy.me/blog/llm-s-are-not-smart-rather-programmin... You just cannot write fast and reliable program neither with C++ nor with Rust, because the fundamental model is broken and nobody's really bothered fixing it.
Modern c# is very nice. And can be fast too
> I would love to hear what he thinks a good programming language is
not OP, but outside of extreme performance critical software I MUCH prefer Swift, C# or python.
C# is really good, but is Swift good enough as true general-purpose language for every platform and OS?
Python? Jesus. One of the worst languages. Half of the community doesn't use static types, `import` is hilariously bonkers. Until very recently (uv) the tooling was absolutely atrocious (they still haven't fixed that dependency confusion issue). Insanely slow.
> I would love to hear what he thinks a good programming language is
Also, not the OP, but I bet it is Python.
- No compile time.
- Not as complex as C++.
- Memory Safety, while they don't care about this apparently, but nice to have.
- Plenty of ergonomic GUI style programming, like PySide (Qt for python).
Of course, I know there are many downsides to python. Such as interpreted languages, especially ones that are duck typed are very slow to run... but that's not one of the OP's complaints.
The article complained that a Rust program can crash when you call `unwrap`—in fact, the author says that's their strongest critique. Python crashes when you call `sys.exit`, so it's no better.
Unfortunately I don't think their critique is really coherent—this is an absurd standard.
Other languages have some kind of exception mechanism so the crashing unwrap gets caught and handled, preferably sanely. Erlang in fact is written around the idea of expecting stuff to crash, and restarting the crashed thing when it happens.
This crash gets caught and handled too: the process exits, the kubernetes pod fails, and the deployment recreates it from scratch. Panicking like this is a request for the infrastructure to turn the whole service off and on again, which is sometimes the correct way to deal with transient failures. The problem here is that the infrastructure was restarting the service with the same bad config every time, causing a crashloop. It's a system design bug.
I have never once seen someone try to catch a NoneType error in Python or an abort()/assert() in C, at least outside of things like HTTP handlers that try to catch everything - which you can also do in Rust!
Hell Python crashes when you do `foo.bar`. If I never have to see a NoneType error again it will be too soon.