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