Enums in Go

The problem isn't so much the lack of enums, it's more that there is no way to do exhaustive pattern matching at compile time. I have seen production systems go down because someone added a variant to an 'enum' but failed to handle that new variant everywhere.

I'm implementing a somewhat complex software in both Go and Rust.

The Rust version is bith shorter and more readable - and probably more efficient - thanks to Rust enums and Rust error handling. I don't understand why golang doesn't copy Rust here. The error handling in particular could be a very simple change.

I am not a huge fan of go:generate and similar projects. They add a level of unknown that goes against the core Golang design values.

I’ve found the enumer [0] library does the job of generating usable helpers without too much pain or any obvious downsides. The ability to generate JSON [un]marshallers is particularly handy.

Still, the lack of enums and enum/sum types remains by far my biggest gripe about Go.

[0] https://github.com/dmarkham/enumer

Enums in Go are not good. Code generation just makes it worse. Both because code generation has a bad smell and because nobody can agree on how to do enums in Go so we just end up with lots of diverging solutions.

Go 2 needs to have more usable enums. And while I'm not a big fan of "adding more stuff" to languages, it wouldn't hurt Go to learn a couple of things from Rust.

I recently wrote a little tokenizer in Go.

The data structure for a token that makes most intuitive sense to me is a tagged union.

So I defined an „const iota“-style enum. Stuck it into a struct that has the appropriate fields to cover all the cases and it was fine.

Having some syntax sugar for tagged unions would be nice. Having exhaustiveness checks if you switch over them, could be useful in some cases.

But that’s not where my mental energy went at all.

Reading the bytes (runes) efficiently and correctly into the data structure however is the part that needs focus. Once the data is in shape, I‘m not „worried“ at all anymore. Sure a bit of extra support is nice, but also kind of superficial.

Also going further, dispatching on them is again never the tricky part. It’s handling the cases correctly and efficiently that has my focus.

In Clojure, a common thing is to write multimethods that dispatch on (namespaced) keywords. Similar in spirit and structure, but each method might now reside in a different namespace or not even be written by you. But I have never worried about exhaustive matching or similar. What’s in the method bodies is the important part.

I really miss value enums from Rust while working with Go, but overall I find Go more intuitive. Didn't know there was a way of auto-generating with stringer, so thanks for the information!

Besides the iota dance hack of "enums" in Go, apparently Go 1.23 is going to bring another one, magic fields.

https://pkg.go.dev/structs@master

What more sane languages would use attributes for, Go 1.23 will do it like this,

    type myStruct struct {
        _  struct.HostLayout 
    }

Lovely design.

I wonder if go ever will get some sort of enum type? Or if int/string based types will be the goto way?

I use https://github.com/orsinium-labs/enum

Use a slice of strings?

    type Color int
    const (
        Red Color = iota
        Green
        Blue
    )

    var Colors = []string{ "Red", "Green", "Blue" }

Now (Colors[Red] == "Red") and (slices.Index(Colors, "Green") == Green).

+1. Here is another alternative. I find this generator more lightweight and better syntax (generated benchmarks and tests are also nice):

https://github.com/nikolaydubina/go-enum-encoding

Oh, the missing wonders of `[...]`: https://go.dev/play/p/GlVp_z3IOEe

I can't take this language seriously. No enums, letter cases defining if something is "public" or "private", generics as an after-thought. To name just a few