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
forsemantics 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.Linesthat 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 (
deferon 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.