Using unwrap() in Rust is Okay (2022)

However, I think it's really easy for a statically-typed-systems user to get a bit too enamored with static types even so, and start trying to stuff too much stuff in there. Anyone who thinks that the job of static types is to make all conceivable errors impossible is invited to go learn Haskell and then spend some time trying to write a non-trivial program, like, say, a GUI that also interacts with the network somehow, using an effects system to its maximum capability to perfectly carefully constrain every single function.

It is academically impure to do things like the author mentions and have a search object that will fail if you call a certain method without having constructed it a certain way. No question. And no question, this impurity can result in bugs in real code in the real world.

On the other hand, if one takes the time to create the absolutely perfect crate for Rust that absolutely perfectly expresses all possible combinations of options and methods that such a package could have, you could conceivably end up with a package with literally 10 times or more the number of types, that requires more steps to create a search than the simpler one, that is in fact so complicated that it turns the simple task of "please look for string x in string y" into something that a new programmer can't even understand anymore, and even a senior programmer might have to fight through some docs and ultimately just copy/paste an example and hope for the best...

... and the designer must ask the question, is that actually better? In practice, and not in theory?

Bugs are not created equal.

The academic worldview implicitly accepts the premise that an infinite amount of work is worth doing to eliminate the smallest possibility of the smallest bug with the smallest consequences.

A coder who lives in the real world needs to examine that premise carefully and decide if it matches their current situation, and if as is quite likely it does not, take appropriate actions. Static type systems offer a fantastic cost/benefit tradeoff in many real-world situations, but there is a point of diminishing returns.

int? in C# is syntactic sugar for the type Nullable. The big issue though is that Nullable only works for value types, not reference types like string (or any classes). C# added "nullable reference types" a few versions ago, but that is just static analyzers in the compiler and IDEs, it doesn't actually enforce anything at runtime. And all of the methods, etc. that are available for value types with Nullable don't work with nullable reference types.

C# has union types as a planned feature, which will also add an Option type that will make it possible to handle nullability for both value and reference types using the same type, and make it so it's actually enforced at runtime.

  - The let-else syntax (Relatively new), anecdotally, removes many of my cases for unwrap. (But this may not apply to how others use it)
  - Unwrap's fine if it makes the code easier-to-read and you know it won't panic for a reason the compiler doesn't know about.