Re:A rough proposal for sum types in Go (2018)
by bborud on Tuesday November 16, 2021 @04:23AM
(#29238552)
Yes, and the point I was making was that I don't think it actually makes things much clearer. One has more syntax and alters the effective return value, the other just states what you will get back regardless of result. From a practical point of view when you are consuming an API, which requires more concentration?
[ Parent
| on HN ]
Re:A rough proposal for sum types in Go (2018)
by Zababa on Tuesday November 16, 2021 @05:16AM
(#29238891)
> From a practical point of view when you are consuming an API, which requires more concentration?
I think the current Go one requires more concentration, or at least more work. Lots of functions return data, err. You have to check for each of these functions if the presence of err means that data is going to be invalid/nil or add it to your code.
The same argument could be made for nil by the way. Since everything can be nil, you have to check for nil often. In languages that make a difference between a type, and a type or nil, this is easier.