The upcoming iterator design for Go 1.23

Original Article ↗ Hacker News Discussion ↗

Go’s planned iterator feature for version 1.23 is stirring debate over whether it enhances or undermines the language’s hallmark simplicity. Supporters argue that standardized iterators, enabled by generics, will make custom data structures and streaming APIs more efficient and consistent with `for range` loops, especially by avoiding large intermediate slices. Critics counter that the syntax feels bolted-on and “magical,” increases cognitive load, and reflects a broader drift away from Go’s original minimalist, easily readable design goals.

Overall reaction to Go 1.23 iterators

  • Thread is sharply divided: some see iterators as a natural, overdue extension; others see them as a betrayal of Go’s simplicity and readability.
  • Many say they personally won’t write iterators but expect to consume them from libraries.

Simplicity, “magic,” and Go’s philosophy

  • One side argues iterators add hidden magic to for range, eroding Go’s “no surprises” ethos.
  • Others counter that Go already has “magic” (init functions, build tags from filenames, built-ins with special cases, goroutines, go: directives, recent for semantics changes).
  • There is disagreement on what counts as “magic”: surprising behavior vs. compiler desugaring vs. conventions like capitalization for export.

Use cases and motivations

  • Strong argument: custom containers (trees, ordered maps, concurrent maps, queues) need a standard iterator shape that works with range.
  • Iterators help:
    • Avoid allocating full slices for large/unbounded sequences.
    • Standardize currently ad‑hoc patterns like row.Next(), scanners, DB row iteration.
    • Enable potential new stdlib APIs like strings.Lines that stream results.
  • Some note that iterators were already being emulated; this just formalizes a pattern.

Design and syntax concerns

  • Many find the function-returning-a-function style verbose, hard to read, and hard to debug, especially with implicit wrapping of the loop body.
  • Comparisons are made to Rust’s and C#’s iterator/yield designs, which are seen as simpler and more ergonomic.
  • Cleanup semantics (defer on iterator functions, cleanup on panic) are cited as a major reason for this particular design.

Generics and broader design trajectory

  • Iterators are framed as a follow-on to generics: once you can build your own containers, you want them to integrate with range.
  • Some lament that Go is incrementally becoming a “kludge” of bolted-on features, drifting from its original austere spirit.
  • Others emphasize that Go’s overarching goal is making production software easier, not preserving minimalism for its own sake.