4 ms·

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

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.

9rx 2y ago
> Go's error handling has four possible cases If you consider (T, error) to be logically coupled, there is actually effectively an infinite number of cases. (T, U, error), (T, U, V, error), (T, U, V, W, error), etc. Although I suspect this take is suffering from trying to project idioms from another language onto Go.
- catlifeonmars 2y ago
  (T, error) is just a special case of (T, E).
  - 9rx 2y ago
    At least we can agree it is (T, E) and not (T or E).
Zanfa 2y ago
> 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. A partial success, that returns both a result and an error definitely makes sense. For example, you’re streaming data over a network, receive some bytes, but get disconnected before it’s complete. It would make sense to have both the data received so far as well as the error, in order to resume. I’m sure there’s an appropriate situation for the 4th case as well.
- WolfCop 2y ago
  Streaming data, there was no error but also no new data available.
  - guappa 2y ago
    That is an error :)
- murderfs 2y ago
  Does it make sense for every function to have those four cases, though?
  - noelwelsh 2y ago
    Exactly. One can think of examples where these cases make sense, but there are many more examples where there are more cases (e.g. there many be multiple kinds of partial successes) or fewer (most functions, which either succeed or fail.) Also, the design requires null values. A point which the replies have ignored.
  - frou_dh 2y ago
    This is why it's table stakes for a decent type-system to have both product-types and sum-types. They comprise both sides of the coin, and you use the one that actually makes sense for the piece of code being written. A justification for Go's deficient type-system I've seen repeatedly over the years, along the lines of "Well actually the occasional function can legitimately return both a result AND an error" is nonsensical. It's basically excusing giving 98% of error-returning functions a semantically wrong return type (a tuple) because it happens to be correct in 2% of cases. Every function should have a semantically correct return type! If a product-type is occasionally correct for an error-returning function, use one just for those functions! And use a sum-type for the other 98% where that is correct for them!
- guappa 2y ago
  Your example doesn't make sense because that's not how the syscall works.
gr3ml1n 2y ago
I can think of situations where all four make sense. Not sure what you mean? result+no error: data returned, no error happened. - Typical function call where you want some data. no Result+error: nothing to return, error happened. - That typical call failed. result+error: partial result, up to error. - Wrote x bytes to disk, then ran out of space. no result+no error: nothing to return, no error. - Data for a passed query. Nothing came back, but that's not an error.
- nejsjsjsbsb 2y ago
  But not every situation. Make illegal state unreprestable is a good ideal.

9rx 2y ago

> Go's error handling has four possible cases If you consider (T, error) to be logically coupled, there is actually effectively an infinite number of cases. (T, U, error), (T, U, V, error), (T, U, V, W, error), etc. Although I suspect this take is suffering from trying to project idioms from another language onto Go.

catlifeonmars 2y ago
(T, error) is just a special case of (T, E).
- 9rx 2y ago
  At least we can agree it is (T, E) and not (T or E).

Zanfa 2y ago

> 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. A partial success, that returns both a result and an error definitely makes sense. For example, you’re streaming data over a network, receive some bytes, but get disconnected before it’s complete. It would make sense to have both the data received so far as well as the error, in order to resume. I’m sure there’s an appropriate situation for the 4th case as well.

WolfCop 2y ago
Streaming data, there was no error but also no new data available.
- guappa 2y ago
  That is an error :)
murderfs 2y ago
Does it make sense for every function to have those four cases, though?
- noelwelsh 2y ago
  Exactly. One can think of examples where these cases make sense, but there are many more examples where there are more cases (e.g. there many be multiple kinds of partial successes) or fewer (most functions, which either succeed or fail.) Also, the design requires null values. A point which the replies have ignored.
- frou_dh 2y ago
  This is why it's table stakes for a decent type-system to have both product-types and sum-types. They comprise both sides of the coin, and you use the one that actually makes sense for the piece of code being written. A justification for Go's deficient type-system I've seen repeatedly over the years, along the lines of "Well actually the occasional function can legitimately return both a result AND an error" is nonsensical. It's basically excusing giving 98% of error-returning functions a semantically wrong return type (a tuple) because it happens to be correct in 2% of cases. Every function should have a semantically correct return type! If a product-type is occasionally correct for an error-returning function, use one just for those functions! And use a sum-type for the other 98% where that is correct for them!
guappa 2y ago
Your example doesn't make sense because that's not how the syscall works.

gr3ml1n 2y ago

I can think of situations where all four make sense. Not sure what you mean? result+no error: data returned, no error happened. - Typical function call where you want some data. no Result+error: nothing to return, error happened. - That typical call failed. result+error: partial result, up to error. - Wrote x bytes to disk, then ran out of space. no result+no error: nothing to return, no error. - Data for a passed query. Nothing came back, but that's not an error.

nejsjsjsbsb 2y ago
But not every situation. Make illegal state unreprestable is a good ideal.