5 ms·
I write a lot of Go. Adding enums nor debugging them has never been a big problem for me. The way that I tackle the problem is to use iota, and then to emit th
by politician 4y ago
I write a lot of Go. Adding enums nor debugging them has never been a big problem for me.
The way that I tackle the problem is to use iota, and then to emit the numeric value into logs.
Later, if I have some time to get fancy, I’ll implement fmt.Stringer using a switch statement.
Sometimes, I’ll implement a ParseFoo function to convert the string representation into the typed representation.
All of this work takes about 5 minutes, and no thought. That’s what we’re talking about here: ~5 minutes of effort per enum.
IMO, you should be spending far more time thinking about which values to add to the enum than the mechanics of string support.
- HL33tibCe7 4y agoThose 5 minutes add up, and in my experience Go newcomers get confused about iota (and the frankly hideous way enums have to be written in general) quite a lot. One of Go’s best aspects is its readability, so it’s unfortunate that it misses the mark here IMO.
- politician 4y agoI think the most distinct enum types I've had in a project was maybe 20? At some point we need to realize that this is bikeshedding.
- Tozen 4y agoI'm really not sure why Go decided against a distinct enum type, instead of repurposing const and getting odd with iota. It comes off as a kind of unnecessary stubbornness, for what should have been easy to add to the language early on. If you look at one of the Go inspired languages, such as Vlang (that has the enum type), it really should not have become an issue. Now, with Go being advanced in age, it comes off as just odd. It becomes reminiscent of the generics debate, where there was such long denial of it being necessary, then suddenly it is understood it should have been done earlier.