Hacker News Reader

Comment by kbenson | Hacker News Reader

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

View on HN

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.

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

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

> 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

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.

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.

Reply on news.ycombinator.com