I;m sorry there wasn't more talk of Go, I think the author might like some of what Go has to offer.
For example, the comparison about maps at the bottom would benefit from seeing the way Go maps work.
There's the single assignment form:
foo := myMap[key]
This returns the zero value of the value type in the map if the key doesn't exist in the map.and the two valued assignment:
foo, ok := myMap[key]
This returns true or false in ok based on whether the value exists, zero value for foo if it doesn't exist.This is actually very like an option type, but what go is missing is the compilation-requirement that you check ok before using the value.... however, go does have the compilation requirement that the ok value gets used somehow, or it'll give you an unused variable compilation error. In practice, this works quite well as a more flexible option type for the simple either/or types (either there was a value or an error).
The thing that's always annoyed me about the way go does this, where extra return values are treated somewhat specially to encourage you to actually check them, if your function returns only a success/failure condition you're either forced to return a dummy value for no reason and ignore it, or allow the condition to go unchecked.
Meanwhile, the actual concept of option type has been around for ages and could have been used instead of trying to twist MRV into it.
Thankfully, all the other newer languages are doing the right thing imo.
Not sure what you mean by needing a dummy value if your function only returns success/failure. That's what a boring old error return is for.
func foo() error
Yes, but unlike having a second result this particular error check need not be touched. To make it so the caller has to check it, I'd have to return a dummy normal return.
If you have
func foo() (string, error)
You can still call it thusly:
foo()
However there are tools to check for unchecked errors like this one: https://github.com/kisielk/errcheck