Or, you know, it could learn a thing or two from C# enums (which are not even that good):
[Flags]
public enum Options
{
Default = 0,
Option1 = 1, // can also be defined as 1 << 1
Option2 = 2, // can also be defined as 1 << 2
Option3 = 4 // can also be defined as 1 << 3
}
The above is a choice, and an enum can be defined normally if it's not a bitmask. .ToString() would even format it correctly if multiple flags are toggled, it can be easily parsed with Enum.Parse<MyEnum>(text) and more. And hell, this is just tolerable implementation. It makes a lot of sense given historical context of C enums, which it's a direct improvement over, but not a step away in what is now considered to be the right direction represented by Rust enums instead.
(Luckily, unlike Go, C# allows to trivially define Result<T, E> class/struct and a method on it in the form of Map(ok => .., err => ...))
I don't think my comment ought to be the trigger for a generic rant against Go enums (or lack thereof). I was just pointing out a motivation for iota to increment in sequence from zero (rather than assigning a random unique value, as OP suggested).
C# enums are strictly worse: they’re C enums, meaning they’re no safer than integers, but they don’t tell you about that.
Go at least does not pretend it has anything like enums or sum types, and that is to its credit. You create a Go integer type, it’s flagrantly shit, but it’s not subtle about it.
C# enums explicitly tell you that and it is well documented. You have easy Enum.IsDefined(enumValue) as well as Enum.GetName(enumValue) which work exactly as advertised. Switches on enum values will tell you to handle the default case too.
They are not ideal by modern standards when you look at Rust. But to state that they are worse than Go's is a new and I can't find a way in which this kind of statement would defensible.
(Luckily, unlike Go, C# allows to trivially define Result<T, E> class/struct and a method on it in the form of Map(ok => .., err => ...))