Go Enums Still Suck

Original Article ↗ Hacker News Discussion ↗

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).