@bugsmith Go enums suck because there are no enums in go, thanks for the clickbait. There are packages implementing them and an ongoing proposal discussion: https://github.com/golang/go/issues/28987
I disagree that it’s clickbait. Go does not have enums, that is undeniable. But we often encounter problems in software development where enums are an effective solution - arguably the right solution a lot of the time. Even if enums are not a language feature of Go, many of us are (rightly or wrongly) doing programming cartwheels to implement them ourselves. So I think an article discussing how one can roll enums or at least enum like behaviour in the language is relevant, and the awkwardness of that experience is captured in the blog’s title.
@bugsmith Title is making a strong qualitative statement about a feature completely absent from the language. Worse than that, it is not covered by the content, which is about “Look how I hand-roll a poor man’s enum in go”.
This kind of strong title not covered by content I call “clickbait” and will always do.
Considering when I clicked the link the result is an error about a database lock in SQLite on a blog, I’m not sure this opinion is coming from a wise and experienced developer.
A language without enums? Interesting… not the choice I would’ve made, but interesting nonetheless. Is there a reason why?
Or having to create such abominations which is especially annoying when you find out you didn’t need one this time.
I mainly develop in C#, and I agree that having to write so much boiler plate for type safety is really boring. C# is not perfect either (it doesn’t have discriminated unions, etc.) but at least it gives type safety out of the box.
However, in general, I think enums are widely misused. I see a lot of cases where they should have been classes with a factory, but ended up being enums with a lot of static functions and switch statements.
