5 ms·
> 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
by bccdee 11mo ago
> 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.
- xwolfi 11mo agoWhy did they name the crash() function "unwrap()" ? Feels weird to me ...
- aw1621107 11mo ago> 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.
- Mauneam 11mo agoFirst, 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.
- rddbs 11mo agoYou 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.
- Mauneam 11mo agoNo, 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".
- bccdee 11mo agoWhat 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.
- josefx 11mo agoSys 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.
- Measter 11mo agoAnd, 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.