hot take: We should rename .unwrap() to .or_panic(). (And .expect() to .or_panic_with().) "Unwrap" is a terrible name for the panicking function, especially since we also have things like .unwrap_or() and .unwrap_or_default() which never panic.

1
0
2

If you have a fediverse account, you can quote this note from your own instance. Search https://hachyderm.io/users/Mara/statuses/115575199307766755 on your instance and quote it. (Note that quoting is not supported in Mastodon.)

RE: hachyderm.io/@Mara/11557519930

I have seen so many production incidents at `$FAANG` triggered because of the liberal usage of `unwrap`, and it always comes down to the same thing

It's the _culture_ in these companies which is constantly pushing workers to do more with less, and deliberately failing to allocate enough time and resources for the deliverables being requested

Changing the name of `unwrap` isn't going to have any impact on this problem; everybody working on these codebases at companies of this magnitude knows that denying the use of `unwrap` or `expect` is a simple `deny` annotation away

Even if they had to write `or_panic` instead of unwrap, they would still do it, because the problem here is not a technical problem, it is a problem of working conditions

This is what we get with an economic model which is centered around making every worker "fungible", and no amount of safety guarantees in the Rust compiler or standard library naming decisions will ever be able to address this fundamental underlying issue

0
0