[the_other_guy]

when I stated my argument I was accused of being ad hominem, making sarcastic, content-free snarks on barely related HN posts, arguing against enums is as stupid as arguing for null pointers (which ironically exist in golang too!), it's not minimalism if you don't have enums, it's intentionally lacking an elementary feature that does exist in almost every other modern (well, in even old) language, you can argue with "deal with it" just like it was the case with package management, error handling and many other features, that wouldn't be as bad as derailing the argument to "enums are not necessary"

also, I feel strong about getting rid of cancer, should I write a treatise about the importance of getting rid of cancer since you may consider that not very important too?

[cle]

Understand before you criticize. There are plenty of scenarios where enums can be undesirable.

One off the top of my head that I run into all the time is in client stubs of service APIs, where a client-side enum representing a string value will break at runtime if the service adds a new string value.

In other words, enums inhibit API evolution.

[erik_seaberg]

API version in use should be negotiated. If a 34.x response needs a value that didn't exist in 33.x, I have to map it to something that 33.x clients understand. If I can't do that, they won't be able to either, and we aren't communicating.

[cle]

API versioning has its own tradeoffs as well. Now there's a negotiation protocol to follow, which introduces a bunch of other issues. E.g. if I'm looking at a field that hasn't changed between versions, then a version mismatch doesn't matter. Clients have to opt-in to new versions, which introduces another set of problems.

I've done a fair amount of Go programming in large teams, mostly doing distributed systems stuff, and I've never run into a situation where I was like "Damn I wish I had enums here." Strings have worked just fine, and we've never had any bugs related to that. I have, however, run into situations where I was like "Wow, good thing I wasn't using an enum here." And in some of our Java code, we've had multiple production issues caused by over-eager devs using enums everywhere. They implicitly enforce a contract on the value of the data, which can be quite undesirable if they don't actually care about the contract (e.g. they're just passing values through to something else).