I disagree. A nil error in Go is most likely a dev forgetting a check. An unwrap() is a dev explicitly saying this should always contain a value. In fact fixing unwrap is as easy as search for unwrap in your codebase and factoring them all out.

> An unwrap() is a dev explicitly saying this should always contain a value

Isn't expect() supposed to cover that case?

No it's the opposite. Unwrap() means the dev said this will never not be set. Expect() is saying if this value is not available exit the program with this user facing error message.

expect() is like unwrap() but you can give a message as an argument.

It is a shame there are so many Rust examples out there with unwrap() all over them, because it's really not something I would want to see in production code. expect() with a message if you know that the only reason this fails is because something else messed up that should have prevented the call in the first place, sure. unwrap()? No thanks. That's why we have the ? operator now.

Agreed, except I don't think people should use expect() since its name is a mistake made early on in Rust: people use it to write

expect("something bad we don't expect")

unwrap_or_else(|| panic!(...))

is clear and doesn't suffer from the naming mistake.