Re:Go and Simplicity Debt Redux
by vanderZwan on Monday June 19, 2017 @05:23AM
(#14585585)
> Right now, to understand how io.Reader works you need to know how slices work, how interfaces work, and know how nil works. If the if err != nil { return err } idiom was replaced by an option type or maybe monad, then everyone who wanted to do basic things like read input or write output would have to understand how option types or maybe monads work in addition to discussion of what templated types are, and how they are implemented in Go.
I can't really follow the argument here: how would using option types replace the existing idiom? Instead of err being a pointer, err is an option type and the only thing that changes is that instead of writing if err != nill, you write if err. And if comparing nill vs option types works in isolation, then I also don't see where the jump to "in addition to what templated types are" comes from, or the connection to slices and maps.
In fact, if Go had option types, would it still need nill at all? By which I mean, on the user-side of things (under the hood I suppose null will be used for implementing an option). Because if it doesn't, and I strongly suspect one doesn't in a language without pointer arithmetic (which Go happens to be), then we can simply replace every nil with an option.
The discussion on how templates interact with existing features and complicate things is fairly clear, but the option types are treated as a lot more complex than they really are. In practice it is a compiler-enforced if-not-null check on pointers, because nill is a type instead of a value. That's about it. That level of compile-time enforcing also seems to be perfectly in line with the safety the Go authors want their compiler to enforce, given how strict it is with errors.
You can easily use them without really understanding what a monad is - I'm living proof of that. The only extra thing you somewhat need to understand is sum types, which are a lot simpler. Then again, Go doesn't have them and their usage overlaps with interfaces - how to deal with that might be a more useful discussion regarding option types in Go.
I can't really follow the argument here: how would using option types replace the existing idiom? Instead of err being a pointer, err is an option type and the only thing that changes is that instead of writing if err != nill, you write if err. And if comparing nill vs option types works in isolation, then I also don't see where the jump to "in addition to what templated types are" comes from, or the connection to slices and maps.
In fact, if Go had option types, would it still need nill at all? By which I mean, on the user-side of things (under the hood I suppose null will be used for implementing an option). Because if it doesn't, and I strongly suspect one doesn't in a language without pointer arithmetic (which Go happens to be), then we can simply replace every nil with an option.
The discussion on how templates interact with existing features and complicate things is fairly clear, but the option types are treated as a lot more complex than they really are. In practice it is a compiler-enforced if-not-null check on pointers, because nill is a type instead of a value. That's about it. That level of compile-time enforcing also seems to be perfectly in line with the safety the Go authors want their compiler to enforce, given how strict it is with errors.
You can easily use them without really understanding what a monad is - I'm living proof of that. The only extra thing you somewhat need to understand is sum types, which are a lot simpler. Then again, Go doesn't have them and their usage overlaps with interfaces - how to deal with that might be a more useful discussion regarding option types in Go.