I saw that article in 2023 and I have mixed feelings. In general there are cases where you want a program to crash and it's a preferable option as opposed to a never-ending chain of handling. For that purpose, unwrap is actually perfect. It is also great for examples, documentation, so that people can see what to expect and how a certain block should behave.<p>But there's the other case(which I've also suffered from). It is tempting to do the fast thing when you are on a tight schedule. One such instance was when we had to deliver something which was arguably undeliverable within the deadline we had. There were two services which were communicating over gRPC, and to make matters worse, not tonic but some custom implementation. But those worked surprisingly well against all odds. But there was a third service where we had to use a regular, plain ol' boring http requests. "I'm returning you the ID as a string inside the response, just cast it to a 32 bit integer and you're good to go" they said. "Fair", I thought: response_id::<i32>().unwrap(), compile and deploy. Needless to say, the ID was not a 32 bit integer. Point is, if you control the entire ecosystem you are working on, unwrap, although undesirable in many cases, is fine. Anything else - handle the errors.