Golang proposal: container/: generic collection types

Original Article ↗ Hacker News Discussion ↗

A proposal to add generic collection types like sets, maps and heaps to Go’s standard library has reignited debate over the language’s evolution from minimalism toward greater abstraction. Supporters argue these features are long overdue, will reduce boilerplate and better support real‑world use cases, especially for library authors. Critics worry that generics, iterators and more complex containers erode Go’s original simplicity and performance-focused design, seeing the changes as a late, somewhat reluctant convergence toward patterns long present in languages such as Java, C# and Rust.

Overall reaction to generic containers proposal

  • Many welcome standard generic collections (sets, typed heaps, etc.) as “better late than never”.
  • Some see it as directly making “ordinary code” easier by avoiding hand‑rolled containers and boilerplate.
  • Others are worried this accelerates Go’s drift away from its original minimalist identity.

Generics in Go: fit and philosophy

  • Several argue generics were ultimately necessary for idiomatic libraries (collections, JSON/API wrappers, channel helpers).
  • Critics say generics don’t mesh cleanly with earlier design choices (e.g., no methods on external types), leading to awkward patterns and runtime workarounds.
  • Defenders say the design prioritizes readability of generic use over ergonomics for generic authors and keeps compile times fast.

Simplicity vs power

  • One camp values Go’s “YAGNI” simplicity and sees more features as opening doors to “clever” and harder‑to‑maintain code.
  • Another camp counters that Go was never on the “Pareto frontier”; its simplicity often pushed complexity into user code (duplicated containers, type assertions).
  • Some lament that Go is converging toward a “corporate/elephantine” language like Java, losing its niche as the simple alternative.

Map/iterators and functional style

  • Debate over Map/filter‑style operations:
    • Pro: shorter, clearer code for common transform patterns; easier reasoning when data is treated as immutable.
    • Con: Go’s verbose lambdas and weaker inlining make them less ergonomic; explicit for loops are clearer and more flexible.
  • Iterators/streams are seen by some as powerful and composable; others highlight new failure modes (e.g., misuse around stopping iteration).

Error handling and ergonomics

  • Some wish Go had adopted a more concise, composable error‑handling construct; current patterns are seen as noisy and prioritizing “sad paths”.
  • Others insist explicit error checks are a core strength and that attempts at syntactic sugar have design pitfalls in Go’s model.

History, timing, and “wasted effort”

  • Multiple comments argue that resisting generics for years caused large amounts of workaround code and technical debt.
  • Others respond that language evolution always implies some “waste”, and the team delayed generics to avoid Java/C++‑style complexity.
  • Backward compatibility guarantees mean the standard library must evolve slowly and carefully; some accept this, others find it frustrating.

Comparisons, ecosystem, and future

  • Frequent comparisons to Rust, Java, C#, Smalltalk, Lisp, JavaScript, .NET, and JVM GCs; views differ on whether Go is catching up or losing its differentiators.
  • Some attribute Go’s success mainly to Google, Docker, and Kubernetes; others say its runtime, deployment model, and tooling stand on their own.
  • Unclear consensus on Go’s long‑term direction: some are content to “ride it out,” others consider moving to more feature‑rich languages.