5 ms·

I'm a Go fan and I love the language, but what I can't really stand is the fact that enums do not really exist, and it's representation (stringification, for ex

I'm a Go fan and I love the language, but what I can't really stand is the fact that enums do not really exist, and it's representation (stringification, for example) is not implemented by default. So far I still haven't found a clean way to have proper enums, and this article shows us that unfortunately neither the author has :(

arendtio 6y ago
I agree, this article is a perfect example of the weak parts of Go. I love Go for many decisions that have been made during its development, but the handling of enumerations is certainly not part of it.
throwaway894345 6y ago
I don't mind that the compiler doesn't provide a default string implementation by default. I'm happy to use string values in my enums (in most cases const string vs int doesn't matter much for performance) for convenience; what I do wish for is full-blown ADTs. I want to be able to express `'Hello' | 'World' | 42 | struct{Name string, Age int} | []int` and know that the compiler will enforce. You can sort of get there with Go through various workarounds and with enough boilerplate (and no, I'm not one to complain about error handling or for loop boilerplate, but the boilerplate to workaround ADTs is much more tedious and much less discernible.
- mssundaram 6y ago
  Do you have any examples of how you would implement a makeshift sum type like your example?
  - morelisp 6y ago
    X interface{} // int(3) | int(5) | []float64 | *Z It sucks.
    - throwaway894345 6y ago
      We can recoup a fair bit more type safety than this if we're interested in going through the effort: https://play.golang.org/p/4Fd7aKRtmvz https://play.golang.org/p/4Fd7aKRtmvz. See my sibling comment for more details.
  - throwaway894345 6y ago
    Here's one such workaround: https://play.golang.org/p/4Fd7aKRtmvz https://play.golang.org/p/4Fd7aKRtmvz It's not great for a number of reasons. First of all, `nil` is always a valid permutation even if we don't want it to be. Secondly, it's a lot of work to express the constraints we want. Thirdly, it's not perfectly type-safe; someone who was determined to shoot themselves in the foot could construct other instances of our "singleton types" if they really wanted to. Fourthly, boxing all of these values will almost certainly cause unnecessary allocations which would be a bummer if we wanted to create a lot of these quickly (this is an implementation detail and may not be any worse than a language with first-class support for sum types).
    - morelisp 6y ago
      Fifth, and most critically for me why it’s not really any better than a comment on an interface{}: a user’s matches won’t be checked for exhaustiveness if you add a new type, let alone them poking around the internals. You can box them safely, but not unbox them.
      - throwaway894345 6y ago
        Yes, that’s an important point; thanks for noting.
  - deleted 6y ago
    [deleted]
int_19h 6y ago
If generics are a representative example, Go will eventually get enums, and probably ones that look very much like what C# or Java have, after years of insisting that you don't actually need them, and that everybody is doing them wrong. ~

arendtio 6y ago

I agree, this article is a perfect example of the weak parts of Go. I love Go for many decisions that have been made during its development, but the handling of enumerations is certainly not part of it.

throwaway894345 6y ago

I don't mind that the compiler doesn't provide a default string implementation by default. I'm happy to use string values in my enums (in most cases const string vs int doesn't matter much for performance) for convenience; what I do wish for is full-blown ADTs. I want to be able to express `'Hello' | 'World' | 42 | struct{Name string, Age int} | []int` and know that the compiler will enforce. You can sort of get there with Go through various workarounds and with enough boilerplate (and no, I'm not one to complain about error handling or for loop boilerplate, but the boilerplate to workaround ADTs is much more tedious and much less discernible.

mssundaram 6y ago
Do you have any examples of how you would implement a makeshift sum type like your example?
- morelisp 6y ago
  X interface{} // int(3) | int(5) | []float64 | *Z It sucks.
  - throwaway894345 6y ago
    We can recoup a fair bit more type safety than this if we're interested in going through the effort: https://play.golang.org/p/4Fd7aKRtmvz https://play.golang.org/p/4Fd7aKRtmvz. See my sibling comment for more details.
- throwaway894345 6y ago
  Here's one such workaround: https://play.golang.org/p/4Fd7aKRtmvz https://play.golang.org/p/4Fd7aKRtmvz It's not great for a number of reasons. First of all, `nil` is always a valid permutation even if we don't want it to be. Secondly, it's a lot of work to express the constraints we want. Thirdly, it's not perfectly type-safe; someone who was determined to shoot themselves in the foot could construct other instances of our "singleton types" if they really wanted to. Fourthly, boxing all of these values will almost certainly cause unnecessary allocations which would be a bummer if we wanted to create a lot of these quickly (this is an implementation detail and may not be any worse than a language with first-class support for sum types).
  - morelisp 6y ago
    Fifth, and most critically for me why it’s not really any better than a comment on an interface{}: a user’s matches won’t be checked for exhaustiveness if you add a new type, let alone them poking around the internals. You can box them safely, but not unbox them.
    - throwaway894345 6y ago
      Yes, that’s an important point; thanks for noting.
- deleted 6y ago
  [deleted]

int_19h 6y ago

If generics are a representative example, Go will eventually get enums, and probably ones that look very much like what C# or Java have, after years of insisting that you don't actually need them, and that everybody is doing them wrong. ~