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

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.

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

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.

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.

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

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.

Were any parts copy pasted from LLM output (and possible changed after)?