3 ms·
In practice this doesn't seem to work. In theory, Go should have a Result interface and two types Data and Error that implement it, and then functions that coul
by bobbylarrybobby 5y ago
In practice this doesn't seem to work. In theory, Go should have a Result interface and two types Data and Error that implement it, and then functions that could error would return a Data or an Error and then... you'd have to call a function like `my_result.Do(callback)`? The fact that idiomatic Go code actually returns (data, err) and checks if err == nil -- and that it's not an error to forget this check -- suggests that the interface paradigm just doesn't work that well.
- jerf 5y agoI have programmed Go for around 8 years now. This is not a problem in practice. I am familiar with Haskell. I know the gospel of sum types. But I don't think it's good engineering to force an inferior solution in to solve a problem I don't have. There are times when it solves problems. It is sort of ironic that as this conversation was occurring here on HN, I was programming with a sum type at work and doing a lot of type switches today. But it was solving a problem for me. Either/Result doesn't solve a problem I have in Go. The vast majority of time a person bashes a sum type into Go, they should be using polymorphism instead of switches. It is a well-known error to try to use a functional programming language as an OO language. It is the exact same error to use an OO language as if it's a functional language. One may be more in line with the zeitgeist, but that just makes it more popular, not a better idea. It's just as silly and just as gauche as the guy who runs to a Haskell community to complain about how they can't figure out how to implement inheritance in a nice way.