Am I understanding that bykozy is claiming that "Rust is memory safe and unreliable" because Cloudflare crashed due to an unhandled exception??
Several core problems with Rust
121–130 of 341 posts
Re: Several core problems with Rust
#122Earlier quoted context omitted.
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.
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…
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.
Re: Several core problems with Rust
#123> 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.
Re: Several core problems with Rust
#124> 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 >> 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 "comp…
[deleted]
Re: Several core problems with Rust
#125You 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.
FAANG engineeers can't code for shit, but the one thing they did get right was when they jumped on the Rust bandwagon
Re: Several core problems with Rust
#126Rust 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% reliabi…
>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…
>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>` 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.
Re: Several core problems with Rust
#127> 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()` f…
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.
Re: Several core problems with Rust
#128Earlier quoted context omitted.
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++ suf…
>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 p…
> 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>> — 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.
Re: Several core problems with Rust
#129> 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()` f…
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.
Re: Several core problems with Rust
#130I 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…
> 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…
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?