3 ms·

I agree with the title, though the age example in the article isn't great. One of the things I see often in code reviews is the wrong use of product types wher

I agree with the title, though the age example in the article isn't great. One of the things I see often in code reviews is the wrong use of product types where sum type would be better. Things like returning error and value separately and the value is meaningless/undefined if there was an error This is much more frequent in languages which make use of sum types hard (looking at you std:: variant) compared to ones that make it easy (like Rust). Of course Go is particularly terrible at it and stubborn in it's design, one of the main reasons I hate using it when forced to.

drekipus 3y ago
Do you mean that, each return type should be union'd with potential error types? If there was an error, the value should be meaningless. I don't understand what your complaint is against returning both the value and the error. (Python dev learning Golang, I like the "return error" idea)
- progbits 3y ago
  In Go you rely on convention that if err != nil, the other value is meaningless and should not be used. You have to remember to check this, and some interfaces break this convention and use eg. error+some partial value, or nil+nil or other combination. With Rust's Result<T> you either get the value, or the error. Never both or neither. Those states are simply unrepresentable. absl::StatusOr does the same in C++, with slightly worse ergonomics. > If there was an error, the value should be meaningless. I don't understand what your complaint is against returning both the value and the error. Think of it this way: why are you even returning a meaningless value in the first place?
- Smaug123 3y ago
  More tersely, returning errors is not the problem. Returning errors and results simultaneously (and relying on context to distinguish them) is the problem. Sums are not well modelled by products.
- kubanczyk 3y ago
  > If there was an error, the value should be meaningless. I don't understand what your complaint is against returning both the value and the error. What TFA says: yeah, just make invalid states unrepresentable in the type system.
- xigoi 3y ago
  No. If there was an error, there should be no value at all.

drekipus 3y ago

Do you mean that, each return type should be union'd with potential error types? If there was an error, the value should be meaningless. I don't understand what your complaint is against returning both the value and the error. (Python dev learning Golang, I like the "return error" idea)

progbits 3y ago
In Go you rely on convention that if err != nil, the other value is meaningless and should not be used. You have to remember to check this, and some interfaces break this convention and use eg. error+some partial value, or nil+nil or other combination. With Rust's Result<T> you either get the value, or the error. Never both or neither. Those states are simply unrepresentable. absl::StatusOr does the same in C++, with slightly worse ergonomics. > If there was an error, the value should be meaningless. I don't understand what your complaint is against returning both the value and the error. Think of it this way: why are you even returning a meaningless value in the first place?
Smaug123 3y ago
More tersely, returning errors is not the problem. Returning errors and results simultaneously (and relying on context to distinguish them) is the problem. Sums are not well modelled by products.
kubanczyk 3y ago
> If there was an error, the value should be meaningless. I don't understand what your complaint is against returning both the value and the error. What TFA says: yeah, just make invalid states unrepresentable in the type system.
xigoi 3y ago
No. If there was an error, there should be no value at all.