Go Enums Still Suck
Go’s approach to “enums” — integer constants driven by `iota` and often augmented with code generation and magic comments — is widely criticized as unsafe, opaque, and far behind what older languages like Pascal or modern ones like Rust and C# offer. Commenters argue that the lack of true sum types and stronger type-level guarantees forces awkward workarounds, hurts readability, and exposes developers to subtle bugs, especially in large codebases. Some defend Go’s simplicity and low cognitive load, but others see its enum story as emblematic of a broader reluctance to adopt well-established type-system advances.
Go “enums” and iota semantics
- Many argue Go doesn’t truly have enums, only integer constants plus
iota, which lack type safety and value constraints. - Some defend them as equivalent to C-style enums: just assigning numbers, with misuse (like assigning 42) being expected in such a limited type system.
- Others counter that older languages (Pascal, Algol 68) had stronger enum/sum-type concepts decades ago, so Go feels regressive.
- There is debate over whether enums themselves are inherently a “hack” in modern language design, with some saying a richer type system should replace them entirely.
Desire for sum types / tagged unions
- Strong sentiment that Go’s real gap is lack of sum types/tagged unions, not just weak enums.
- Rust/Zig/ML-style enums are held up as better models, particularly for error handling and tree-like data.
- Nullable pointers are noted as a limited sum-type pattern, but many see this as insufficient.
Comment-based codegen and DSLs
- The article’s approach using magic comments (
//go:generate, ad-hoc DSL in comments) is widely criticized as brittle, opaque, and tooling-dependent. - Some see it as “idiomatic Go” given the language’s hostility to macros and richer type features; others find that an indictment of Go’s power.
- Alternatives proposed: explicit structs/arrays, real DSLs with separate generators, or using CSV/Sheets for tabular data.
Readability, verbosity, and maintenance
- One camp prefers explicit, verbose structs with named fields for maintainability and onboarding, especially with many mixed-type fields.
- Another camp values brevity and argues that too much boilerplate increases cognitive load; tools/IDEs could visualize compact representations better.
- Disagreement centers on whether shorter, denser constructs help or hurt comprehension in large teams.
Broader critique of Go’s design direction
- Some see Go as intentionally underpowered: low abstraction, basic type system, and conservative stance on features (sum types, richer generics, better enums, Result/Either types).
- Others argue Go hits a sweet spot for “shipping over cleverness,” with low cognitive load and enough power for many backend and infrastructure tasks.
- There is concern that Go’s popularity crowds out more advanced “C successors,” while others feel Go simply filled a real gap (fast, GC’d, relatively simple).