The upcoming iterator design for Go 1.23

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.