3 ms·

I tried Go and I have an opposite experience. To me Go looked like a very limited, incomplete and non-principled language that makes easy things look easy but h

I tried Go and I have an opposite experience. To me Go looked like a very limited, incomplete and non-principled language that makes easy things look easy but hard things ugly or (near) impossible. I put it on the same shelf as Python and Basic. Things like using product type instead of sum type for returning errors really put me off. But that's probably due to past experience and personality type. I mostly enjoy working in powerful and expressive languages: e.g. Rust, Scala, C++. // edit: oh, someone have already said that: can't love Rust and Go at the same time ;)

maccard 5y ago
> 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)
- dthul 5y ago
  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.
- pkolaczk 5y ago
  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.
  - tialaramex 5y ago
    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.

maccard 5y ago

> 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)

dthul 5y ago
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.
pkolaczk 5y ago
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.
- tialaramex 5y ago
  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.