`iota` is maybe the only language feature of Go that I would actually support removing. Obviously, they never will because it would be a breaking change. Its just so vestigial. There's literally no reason to use it, and a very big reason why you shouldn't: The encoded value can change any time you re-compile your program, so you can't <i>actually</i> use it for anything where the value of the enum leaves the process that instantiated it (e.g. marshaling to JSON and sending over the wire). That's a terribly poor characteristic for a feature in a "systems" (emphasis on plural) programming language to have, one would think.
Ada has excellent enumeration types, and subtypes, and compile-time checking of case statement coverage for enum values, and an optional representation mechanism to control the binary value for each (symbolic) enum value. I'm not aware of any other language with that kind of enum type system.<p>See e.g. <a href="https://adaic.org/resources/add_content/docs/craft/html/ch05.htm#5.9" rel="nofollow">https://adaic.org/resources/add_content/docs/craft/html/ch05...</a>
If you're using protobufs anyway, you can get also get this functionality generated by using a proto enum: <a href="https://protobuf.dev/reference/go/go-generated/#enum" rel="nofollow">https://protobuf.dev/reference/go/go-generated/#enum</a>. It works really nicely and has all the features mentioned in the article.<p>One added benefit is it serializes/deserializes safely (even when you add / remove values), so you can persist and read back values without a problem - even to a different language.
A thing that so many enum solutions miss is that you have to have a path for a value outside of the current definition, or you lose a lot of flexibility in compatibility with any data that crosses wires or disks. Sounds fine for a lot of cases, of course, but in a world of mixed deployment fleets working on data, you pretty much have to have a way to allow a value that is not part of your current definition, or you are basically placing a "poison pill" on your system.
Go and Python have OK enums. I will use them, but they could be simpler/more expressive. This begs the question: Is there an obstacle to releasing better enums in the next Python and Go versions? If the concern is about breaking backwards compatibility, I would be OK with a new type. Is it a culture issue, ie that Python and Go programmers don't use enums much? (Chick + egg here)<p>Rust's enums are great. No "auto" boilerplate if not mapping to an integer, exhaustive pattern-matching, sub-types etc.
If people are spending this much time circumventing your language design, you oughta take a look inside. Go "enums" suck and limit the language.
> <i>Go doesn’t technially have Enums and it is a missing feature in my book but there is a Go idiomatic way to achieve roughly the same thing.</i><p>Oh, so it's a lot like Python then.<p>> <i>This is fine however it is nothing but an integer under the covers this means what we actually have is:</i><p>Oh, so it's a lot like C++ then.<p>> <i>But what you notice here is we have no string representation of these Enums so we have to build that out next</i><p>Have to!<p>Yes this still all sucks. (But at least there's ugly historical precedent!)
It's kind of strange to see them complain about enums and then promote a DSL-specific tool they made for generating enums.<p>At the same time, Go has generators built in and can generate enum tables, enum to strings, and other things they have shown. I am unsure why they didn't do it the "Go" way.
I love Go's lightweight, somewhat implicit style of doing enums.<p>You just declare an int type, and then a list of constants of that type.<p>People are complaining about 'iota' here, but I think it's slick and great. It combines so nicely with eliding types and values from subsequent const declarations:<p><pre><code> type MyEnum int
const (
Value1 MyEnum = iota
Value2
Value3
...
)
</code></pre>
Nice and simple. Most of the syntax is just the enum value identifiers. And it works well for bit flags too:<p><pre><code> type MyFlags int
const (
Flag1 MyFlags = 1 << iota
Flag2
Flag3
...
)
</code></pre>
Most of the above syntax isn't specific to enums (so you're already getting a lot of other things from it). The only enum-specific syntax is iota and the eliding type/value rule.<p>People seem to want their languages to have all sorts of guardrails, but I find many of these cumbersome. Go gives me the one enum guardrail I care about: The enums are different types, so I can't use a MyEnum as a MyFlag, or vice versa.<p>I've worked on giant Go codebases, with Go-style enums all over the place, and the lack of compiler-enforced exhaustive enum switches just hasn't been a problem. And it's nice to be able to use non-exhaustive switches, when you want them. Go is simple and flexible here.<p>The article criticizes Go incorrectly with statements such as these:<p>> This also means any function that uses these or a struct that contains these can also just take an int value.<p>> Anywhere that accepts an Operation Enum type will just as happily accept an int.<p>This is just not true. Here's an example you can run: <a href="https://go.dev/play/p/8VGufuxgK6b" rel="nofollow">https://go.dev/play/p/8VGufuxgK6b</a><p>The above example tries to assign an int variable to a MyEnum variable, and gives the following error: "cannot use myInt (variable of type int) as MyEnum value in variable declaration"<p>This error directly contradicts what is claimed in the article. Perhaps they mean that MyEnum will accept an integer literal, in which case I would argue that a guardrail here is silly, because again the problem just doesn't really come up in practice. Regardless, the author is not being very precise or clear in their thinking.
> Anywhere that accepts an Operation Enum type will just as happily accept an int. This is a real pain as it almost completely negates the work we have done here.<p>Is this a real problem? If there's a function signature that accepts `Operation`, the caller must explicitly cast the `int` to `Operation`. At that point, it's the caller's own fault.<p>So I'm not really following what this is solving. As demonstrated in the article, sometimes you want string constants, sometimes you want `iota`, other times you want `1 << iota`. I like that Go doesn't dictate which I have to use if I declare an "enum".
I have a totally tangential ramble queued up on this topic.<p>I like philosophy and I read it as a total amateur. <i>Naming</i> is a big topic in modern philosophy [1] with a huge amount of depth. I think of it in terms of my naïve understanding of Wittgenstein's later work and the idea that the meaning of a word actually comes from its usage within the context of a set of collaborating agents.<p>If I say to a programmer "use a vector", that will mean something specific if we are writing C++ and I want to use a resizable array. And it could mean something totally different in the context of a 3d rendering engine.<p>I think of how often I see words like "Context", "Session", "Kernel" and all of their myriad uses.<p>So I see articles like this as just a pointless argument because we are crossing some boundary between distinct language games. The author of this article thinks "Enum" means one thing. But it is actually the case that "Enum" is unspecified outside of some particular context. And in this case, the author is bringing some outside context and trying to reuse it inappropriately.<p>1. <a href="https://en.wikipedia.org/wiki/Naming_and_Necessity" rel="nofollow">https://en.wikipedia.org/wiki/Naming_and_Necessity</a>
If you are already using gRPC in your codebase, then you can define your enums with Protobuf, which does much of the same as the tool shown in this article.
What I like about Go is not the language itself (I'm not a language designer but I dislike a lot of choices that Go makes) but the entire culture around it of doing things the idiomatic way and moving on. I'm someone who, if you give them a tool that's flexible, will spend time optimizing it. And I'm already busy optimizing other stuff so it's nice to have something constant to build upon.<p>Oh and you don't <i>have to</i> use large power-hungry IDEs that don't integrate with any sort of config management to get a decent experience! (/hj)<p>If I ever learn Haskell it's over for y'all though.<p>(Agree with OP btw, using codegen to get the enums I want is a workable remedy for Go's lack of enums.)
Go's iota is probably one of the worst ideas in all programming languages.<p>Not a full typesafe enum type, the same clunky "enums" (assigned constants) available in C, but they bother to implement an auto-incremented counter.<p>So you can't depend on the enum for exhaustiveness warnings e.g. on switch statements, type checking, or correctness, but you do get a useless numeric association autogenerated with iota - so that you can lose the association if you re-order your enum values that you have serialized earlier and want to reload in the future.
The root cause is wanting to support fixed-size array types in structs, which means nothing can require initialization and everything needs a zero value. The caller can just modify every field directly.<p>This is sort of like how network protocols can’t statically guarantee enums are valid either. When sending bits over the wire, you can send any bits you like. There can be “values reserved for future use,” but to deny their use, you need a runtime check.<p>A similar solution works in Go. A runtime check in a constructor function will fix it. The enum’s value would need to be returned as an unexported field in a struct, which is the only way to guarantee that it’s not writable, except by copying it from another valid value.<p>I don’t see a particular reason why Go couldn’t make this easier.
Anyone writing a compiles to go, go++ yet? There are generators for better enums, sum types, and more. Bring them all together! I'm only kinda joking.<p>Im also curious now if the Typescript checker was written in a way that it could be adapted to new languages easily.
You should not use these enums with ints++ in security sensitive applications, because they're sensitive to rowhammer attacks.<p>Use uint64s with minimal bit overlap.<p>Maybe nice to include in this ultra-advanced enum libray
It has always been surprising to me how primitive Go really is, for no really good reason.<p>I understand the evolution of C, it made perfect sense back when it was invented. And the limitations were necessary due to the wide array of architectures and extremely limited computers of the time in every dimension (CPU speed, IO speed, RAM size, disk size, etc).<p>Many of those dimensions have been improved by several orders of magnitude, and both compilers and runtimes can afford to be comprehensive. Yet we get this ham-strung language out of the gate.<p>Very disappointing.
“Anywhere that accepts an Operation Enum type will just as happily accept an int.”<p>Hey! Just like in C! I digress, I think the issue is that the author comes from another language where enums are a thing. In go, they aren’t. Enums should be types. Types that don’t infer to an int. Use an interface. Be happy.
I generally agree that this is a big problem with Go, so I don't want to quibble too much, but the author acknowledges that the language doesn't have enums and that they're just trying to use this feature like enums (TBF, this is common advise on the internet and a <i>lot</i> of code does this): instead the author should be thinking "how do I solve this problem without enums since they don't exist?"<p>I'd be willing to bet that there's just a better way to do whatever the actual real-world example they want to achieve is (this was not entirely clear to me from the examples in the post).<p>Like I said though, that doesn't mean that (real) enums wouldn't be an even better way to do it than whatever the Go way is for a given problem, so I don't want to quibble too much since I think this is one of my biggest day-to-day complaints about Go, but it's worth pointing out that the premise can be flawed and that it's still a problem in the language, these two things aren't completely orthogonal.<p>TL;DR — Instead of pulling in a code generator and another library, it may be good to think of alternate ways to do the same thing without a lot of extra code footprint.
Enums suck in a bunch of languages including C#. It has binary compatibility issues that need consideration along with some other gotchas and shortcomings.<p>So much so that much of the dotnet official stuff, ie asp.net, use static classes with string fields instead of enums.<p>Unfortunately that doesn't play well with libraries that have enum support like entity framework. PITA.<p>One saving grace is the ability to create extension methods on enums.
It's actually the coolest thing about Go enums, that they just it – enums.<p>Developers with a background in other languages assume all enums' use cases need string representation. Well, no. They are needed sometimes, but not always.<p>The same with the ability to pass int to the enum. Author says:<p>> Anywhere that accepts an Operation Enum type will just as happily accept an int.<p>Well, this is simply not true. [1] You'll have to cast your int into your enum, which is totally fine if it's your intent. Granted, there are plenty of valid cases where you need validated input, especially for the public libraries. But hey, not every code is a publicly facing library, and not all need this validation. Why spend CPU and memory on something that probably won't be needed, and that can be implemented with the existing language primitives?<p>In the end, the author did a great job of solving his own requirements around enums and even wrote a code generator that helps him generate this for millions of enum types per second. :)<p>[1] <a href="https://play.golang.com/p/Ch-IZ26p0v8" rel="nofollow">https://play.golang.com/p/Ch-IZ26p0v8</a>
I love Go. Especially how the devs stubbornly refuse to learn anything from Java, but stumble boneheaded into everything that Java solved over the years. Generics? We don't need that .. (time goes on) .. okay, damn it. Here! Generics! Enums? We don't need that, just do iota/integers!<p>How long will it be this time until the Go devs accept that Java Enums are a safer and better abstraction over integers for the cases where you'd want an Enum? And that they allow something like EnumSet, which are type-safe bitsets, without everyone having to do that by hand?
Go doesn't have enums and as such they cannot suck. Something that is non-existent can't be good or bad. The title is clickbait. Go has constants, and they have a great feature for defining constants (iota).
<p><pre><code> func (o Operation) IsValid() bool {
if o == Unknown {
return false
}
return true
}
</code></pre>
Why, oh why don't people just write<p><pre><code> return o != Unknown
</code></pre>
This is so common in the code that I'm seeing on the Internet, on GitHub etc. Is it because people don't understand booleans?
Pascal in its original 1970's design,<p><pre><code> type myEnum = (value1, value2, value3, value4)
</code></pre>
Naturally that is too advanced and slows compile times.
>>> But what you notice here is we have no string representation of these Enums so we have to build that out next, for this I just use a map[Operation]string and instantiate this with the defined string constants.<p>Cries in I18N...