Taggart Nov 19

Buried in this nicely-detailed RCA is a pretty damning fact:

Cloudflare left .unwrap() in mission-critical Rust code.

For non-Rustaceans, .unwrap() handles a type called Result that can either be Ok with a value, or an Err with an Error. The whole point is to gracefully handle errors and not let panics make it to production code. But unwrap() assumes there's a value to extract without safeguards.

I use .unwrap() sometimes! Usually when there's a logical guarantee that the result can never be an error. But I make sure to purge it from critical processes for exactly this reason.

https://blog.cloudflare.com/18-november-2025-outage/

Show threadRussell

@mttaggart If people aren't supposed to use it then it should be removed from tutorials and linters should default to alerting, otherwise the language will get the same reputation as, say, PHP because practically every tutorial I've seen about Rust teaches it the wrong way by default and rarely mentions the different correct ways.

I would consider going as far as deprecating it since it's such a massive foot-gun.

Nov 19 at 4:12amPhanpy
Show threadTaggart Nov 19

@zimzat It's a design choice to panic sometimes. It has its uses, but not in code that must never panic.

Linters absolutely have this config, and as far as tutorials, I don't think the Book could be clearer.

It sounds like you're asking a language to prevent introspection into an enum's values, which doesn't make a lot of sense to me.

https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html#shortcuts-for-panic-on-error-unwrap-and-expect

Recoverable Errors with Result - The Rust Programming Language

Show threadRussellNov 19

@mttaggart To repeat:

The linters don't have it _on_ by default, meaning it's a foot-gun every newbie will hit directly into production. If it takes the wizened knowledge of the tribe to prevent that then the language needs to improve. Occasionally valid usage is no excuse, especially given the language has per-line overrides (double opt-in).

When I evaluated Rust initially and saw `unwrap` everywhere it seemed like a hot mess. Calling it `unwrap_or_panic` would make it obviously problematic.

Show threadKhleedrilNov 19

@zimzat @mttaggart I'm absolutely with this. Calling it unwrap_or_panic solves all problems.

#rust

Show threadzbrownNov 19

@zimzat @mttaggart consider however that PHP ‘done wrong’ almost immediately leads to bizarre, potentially undefined, behaviours, often ripe for various exploitations.

But unwrap? It's entirely well defined, we know exactly what it'll do, and you explicitly invoke it. Is something labeled ‘crash this program if an error happened’ really a foot gun?

Should PHP ban use of `exit(1)` in a `catch` block?

Show threadRussellNov 19

@zbrown @mttaggart

> Is something labeled ‘crash this program if an error happened’ really a foot gun?

If it were actually labeled that then no, except that's only what it does and not what it's called, so yes it's a foot-gun. The lack of a default-on lint calling it out makes it doubly so.

The word `unwrap` has no connotations of "or panic" but saying `unwrap_or_panic` would be make it explicit and easier to call out at a glance.

Show threadEndlessMasonNov 19
@zimzat @zbrown @mttaggart
People also got upset about "or die" being everywhere in perl, so you can't really win.
Show threadRussellNov 19

@zbrown

> Should PHP ban use of `exit(1)` in a `catch` block?

Probably, ideally, yes.

In a modern PHP application there should only be one `exit` in the entire application: within the equivalent of the `fn main` entry point. All other exceptions should either be handled or bubble up to that point so their trace can be logged and `main` decides what to do. There definitely shouldn't be any `exit` calls in deeply nested code.

Rust's Result is supposed facilitate that same pattern.