5 ms·

I have had the exact same problem with Go recently. I have just started using it and have been disappointed to see that, for a language that claims to be modern

I have had the exact same problem with Go recently. I have just started using it and have been disappointed to see that, for a language that claims to be modern, it doesn't have proper sum types/enums OR convenient product types/tuples. Tuples can be emulated using structs but it can generate a lot of boilerplate for a single function. The only alternative to express iterating over "zipped" lists is to have the two lists side by side and iterate using an integer. However, sum types are just plain missing. I guess interfaces help, but they're really limiting in what they allow and even regular C-style enums are painful and can't be checked for exhaustivity at compile time. Does anyone have tips on what the "idiomatic" solutions are for these problems?

jerf 5y ago
There are times when sum types are the best solution, but in many cases, interfaces are the solution. But, interfaces as they are designed to be used, not just interfaces used to label a set of types that you then constantly type switch between. See: http://www.jerf.org/iri/post/2960 http://www.jerf.org/iri/post/2960 This is true of OO languages in general, not just Go.
- bobbylarrybobby 5y ago
  In practice this doesn't seem to work. In theory, Go should have a Result interface and two types Data and Error that implement it, and then functions that could error would return a Data or an Error and then... you'd have to call a function like `my_result.Do(callback)`? The fact that idiomatic Go code actually returns (data, err) and checks if err == nil -- and that it's not an error to forget this check -- suggests that the interface paradigm just doesn't work that well.
  - jerf 5y ago
    I have programmed Go for around 8 years now. This is not a problem in practice. I am familiar with Haskell. I know the gospel of sum types. But I don't think it's good engineering to force an inferior solution in to solve a problem I don't have. There are times when it solves problems. It is sort of ironic that as this conversation was occurring here on HN, I was programming with a sum type at work and doing a lot of type switches today. But it was solving a problem for me. Either/Result doesn't solve a problem I have in Go. The vast majority of time a person bashes a sum type into Go, they should be using polymorphism instead of switches. It is a well-known error to try to use a functional programming language as an OO language. It is the exact same error to use an OO language as if it's a functional language. One may be more in line with the zeitgeist, but that just makes it more popular, not a better idea. It's just as silly and just as gauche as the guy who runs to a Haskell community to complain about how they can't figure out how to implement inheritance in a nice way.
couchand 5y ago
It's been a while since I've written Go but back then the idiomatic solution was a C-style enum and a fair amount of hope.

jerf 5y ago

There are times when sum types are the best solution, but in many cases, interfaces are the solution. But, interfaces as they are designed to be used, not just interfaces used to label a set of types that you then constantly type switch between. See: http://www.jerf.org/iri/post/2960 http://www.jerf.org/iri/post/2960 This is true of OO languages in general, not just Go.

bobbylarrybobby 5y ago
In practice this doesn't seem to work. In theory, Go should have a Result interface and two types Data and Error that implement it, and then functions that could error would return a Data or an Error and then... you'd have to call a function like `my_result.Do(callback)`? The fact that idiomatic Go code actually returns (data, err) and checks if err == nil -- and that it's not an error to forget this check -- suggests that the interface paradigm just doesn't work that well.
- jerf 5y ago
  I have programmed Go for around 8 years now. This is not a problem in practice. I am familiar with Haskell. I know the gospel of sum types. But I don't think it's good engineering to force an inferior solution in to solve a problem I don't have. There are times when it solves problems. It is sort of ironic that as this conversation was occurring here on HN, I was programming with a sum type at work and doing a lot of type switches today. But it was solving a problem for me. Either/Result doesn't solve a problem I have in Go. The vast majority of time a person bashes a sum type into Go, they should be using polymorphism instead of switches. It is a well-known error to try to use a functional programming language as an OO language. It is the exact same error to use an OO language as if it's a functional language. One may be more in line with the zeitgeist, but that just makes it more popular, not a better idea. It's just as silly and just as gauche as the guy who runs to a Haskell community to complain about how they can't figure out how to implement inheritance in a nice way.

couchand 5y ago

It's been a while since I've written Go but back then the idiomatic solution was a C-style enum and a fair amount of hope.