I feel this article misses the point in many cases. Take, for example, error handling. It's labourious in Go, but that's not the only issue. I'm not going to go into all the details in this comment (others have covered this at length) but:
1. Go's error handling has four possible cases (result and no error, no result and error, result and error, no result and no error) when only two make sense.
2. A consequence of the above is that it requires null values (nil in Go)
I don't see how this can be considered good design.
1. Go's error handling has four possible cases (result and no error, no result and error, result and error, no result and no error) when only two make sense.
2. A consequence of the above is that it requires null values (nil in Go)
I don't see how this can be considered good design.