Hacker News Reader

Comment by maccard | Hacker News Reader

> Things like using product type instead of sum type for returning errors really put me off.

Can you share some practical use cases where the sum type has an advantage? Personally I find go's explicit error type, along with the convention of it being called err everywhere to be really helpful and clear when working through the control flow of a program.

What does a more "powerful and expressive" language give you day to day that golang doesn't? (Generics being the first obvious example, but I have to agree that there are a handful of use cases where they're useful)

View on HN

A product type forces the language to have a special "invalid" state for every type like Nil, and this reminds me of all the problems related to null handling I know from java - like forgetting to check for null / Nil.

A product type also allows returning weird states: no error and no value, or both error and value. I strongly believe that invalid states should be unrepresentable, rather than allowed by the type system and then fought by discipline and tooling.

Also, if there is actually an invalid state for the result type, and your type system has a sum type here, it can implement the sum type by overlaying it, producing machine code that's just as nice as for old school C or C++ programs yet programs that have readable sum types. The actual best of both worlds.

Rust for example promises that Option<NonZeroU32> is the same size (four bytes) as u32, even though it has much more appropriate semantics for some cases. I can't accidentally end up with a zero where I wanted anything else, and I can't easily forget to handle the None case where there wasn't a non-zero answer.

The return types of fallible functions map naturally onto sum types. By using product types instead there is a semantic mismatch. You get an error and a value but only one of those is valid. So you need to follow certain code idioms to get back the sum type semantics whereas this is something the type system could handle for you. Go's reasoning for that might be that they didn't want to have the complexity of sum types in the language, which is fair but is a tradeoff.

Reply on news.ycombinator.com