3 ms·

I think what this comment is missing is any sort of analysis of how your experience maps to the general go user, and an opinion on while you've never needed eit

I think what this comment is missing is any sort of analysis of how your experience maps to the general go user, and an opinion on while you've never needed either whether you think it could have provided any benefit when used appropriately. For example, and option type with enums combined can ensure return values are checked by providing a compile time error if a case is missing (as expressed in the first few examples of the readme).

jurschreuder 2y ago
I know it can, the compiler can do one more "automatic" unit test based on the type checking system. But they decided not to add enums because it conflicted and overlapped too much with interfaces. I just want to add "my" experience that personally, yes maybe you can argue enums are nice, but I never missed them in Go. I personally agree with the Go team on how they argue and for me it would be a step back if they listened to the herd that does not take all sides of the story into consideration but just keeps pushing enums. Try/catch is just a really bad thing all "hacky solution" alarm bells go off for me if you want to change error handling to giant try/catch blocks.
- lelanthran 2y ago
  > But they decided not to add enums because it conflicted and overlapped too much with interfaces. I'm very curious now about how it might conflict and/or overlap with interfaces. To reach the goal of an enumeration type (and all the strong type-checking that that brings with it), enums could look as simple as: type DayNames enum { Sunday Monday Tuesday Wednesday Thursday Friday Saturday } ... func isFunDay (dow DayNames) { // This must fail to compile, because there is an unhandled enumeration switch { case Sunday: ... case Monday: ... case Tuesday: ... case Thursday: ... case Friday: ... case Saturday: ... } ... } ... isFunDay (0) // Compile failure var x int isFunDay (x) // Compile failure And I don't see how that conflicts or overlaps with interfaces.
  - jurschreuder 2y ago
    I think something like when a variable type in an enum was an interface it would destroy the galaxy or something, not 100% sure, would have to look it up... 1 sec. Here you Go: https://go.dev/doc/faq#variant_types https://go.dev/doc/faq#variant_types
    - lelanthran 2y ago
      > I think something like when a variable type in an enum was an interface it would destroy the galaxy or something, Hah :-) > Here you Go: https://go.dev/doc/faq#variant_types https://go.dev/doc/faq#variant_types Not quite the same: Variants are a constrained list of types. Enums are a constrained list of values. Let's assume that I agree with the reasoning for not having a constrained list of types. It still doesn't tell me why we can't have a constrained list of values.
- hectormalot 2y ago
  I largely agree with your sentiment. Go’s simplicity is what makes it such a useful tool for me. It’s worth protecting, and that means setting a very high bar for proposals that add new things to the language. However, 2 things I would be enthusiastic about if it got included in the language: - having ‘?’ As syntactic sugar for ‘if(err != nil) …’. Would make code more easily readable, and I think that is a benefit for programmers trying to keep things simple. - Sum Types. I’ve had a few cases where this would’ve been very useful. I consider the ‘var state customtype = iota’ a bit too easy to make mistakes with (eg exhaustive checking of options). Like generics, I hope that when that happens, they take a very deliberate approach on doing it.

jurschreuder 2y ago

I know it can, the compiler can do one more "automatic" unit test based on the type checking system. But they decided not to add enums because it conflicted and overlapped too much with interfaces. I just want to add "my" experience that personally, yes maybe you can argue enums are nice, but I never missed them in Go. I personally agree with the Go team on how they argue and for me it would be a step back if they listened to the herd that does not take all sides of the story into consideration but just keeps pushing enums. Try/catch is just a really bad thing all "hacky solution" alarm bells go off for me if you want to change error handling to giant try/catch blocks.

lelanthran 2y ago
> But they decided not to add enums because it conflicted and overlapped too much with interfaces. I'm very curious now about how it might conflict and/or overlap with interfaces. To reach the goal of an enumeration type (and all the strong type-checking that that brings with it), enums could look as simple as: type DayNames enum { Sunday Monday Tuesday Wednesday Thursday Friday Saturday } ... func isFunDay (dow DayNames) { // This must fail to compile, because there is an unhandled enumeration switch { case Sunday: ... case Monday: ... case Tuesday: ... case Thursday: ... case Friday: ... case Saturday: ... } ... } ... isFunDay (0) // Compile failure var x int isFunDay (x) // Compile failure And I don't see how that conflicts or overlaps with interfaces.
- jurschreuder 2y ago
  I think something like when a variable type in an enum was an interface it would destroy the galaxy or something, not 100% sure, would have to look it up... 1 sec. Here you Go: https://go.dev/doc/faq#variant_types https://go.dev/doc/faq#variant_types
  - lelanthran 2y ago
    > I think something like when a variable type in an enum was an interface it would destroy the galaxy or something, Hah :-) > Here you Go: https://go.dev/doc/faq#variant_types https://go.dev/doc/faq#variant_types Not quite the same: Variants are a constrained list of types. Enums are a constrained list of values. Let's assume that I agree with the reasoning for not having a constrained list of types. It still doesn't tell me why we can't have a constrained list of values.
hectormalot 2y ago
I largely agree with your sentiment. Go’s simplicity is what makes it such a useful tool for me. It’s worth protecting, and that means setting a very high bar for proposals that add new things to the language. However, 2 things I would be enthusiastic about if it got included in the language: - having ‘?’ As syntactic sugar for ‘if(err != nil) …’. Would make code more easily readable, and I think that is a benefit for programmers trying to keep things simple. - Sum Types. I’ve had a few cases where this would’ve been very useful. I consider the ‘var state customtype = iota’ a bit too easy to make mistakes with (eg exhaustive checking of options). Like generics, I hope that when that happens, they take a very deliberate approach on doing it.