go-enum VS goderive

There's also https://github.com/abice/go-enum, which I decided to use after evaluating multiple such tools a while ago, but I don't remember exactly why it came out on top for me. Also, both (and others) have evolved since then, so things might have changed.

One nice thing go-enum does is to even generate the consts, just from a list of values in a comment.

While not perfect, there are ways to generate enums automatically using go:generate, e.g. https://github.com/abice/go-enum

I wouldn't write a macro to save a couple of lines, but I would definitely use (not even write, just use) a macro for something like generating enum [de]serialization for both JSON and BSON in one line. Go, even with generics, still has no way of abstracting extremely common patterns like enums without separate generator tools. Clearly someone thought the macro was useful here, but without a macro they had no choice but to write a separate tool.

Ive found enums in Go are a pain point, especially across an organization because there are many valid ways to implement it. It's also fairly verbose to implement. The way Ive solved for it is code generation. This is a pretty good library that my team uses in production https://github.com/abice/go-enum

I've worked in a few different languages and Go doesn't seem all that unique in the way that it doesn't provide an ENUM primitive. However, I looked around a bit and found go-enum which seems pretty neat. Also, I have no problem writing a custom string or int/iota type. In some cases you want to be able to serialize/deserialize with them -- and in others you don't need that.

Along that same line you can take it a step further and generate the iota block too with this tool https://github.com/abice/go-enum

Looks like this does what you want: https://github.com/abice/go-enum

I found https://github.com/awalterschulze/goderive but haven't used anything like it besides mockgen

Now, am I going to do the same with a library like goderive just so I can use FP techniques to get, amongst some other things, less nil checks? No. Probably not. If I wanted to use primarily FP techniques in my code, I would probably be using something else in the first place. Go isn't a great environment for guaranteeing immutability for starters, so anything like that is necessarily going to be an incomplete experience. And in the bargain, my code would, in my opinion at least, be less readable and maintainable.