[Mauneam]

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.

[rddbs]

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.

[Mauneam]

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

[bigstrat2003]

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

[bccdee]

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.

[josefx]

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.

[bccdee]

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.

[Measter]

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.

[jacquesm]

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.

[vacuity]

You don't have to call unwrap()...Rust provides alternatives, which are very prominent.