Go Iterators Are Bad

Go 1.23’s new iterator design has sparked backlash because it makes Go feel more “functional” and syntactically magical than many programmers expect from an unapologetically imperative language. The core friction centers on how iteration is expressed: range loops are transformed into nested function calls with “yield”-style control flow, and breaks/escape paths get rewritten into boolean returns. Supporters like the generator-like feel and the ability to run cleanup via defer inside the iterator’s control flow, but critics say the resulting syntax and semantics are harder to read, harder to reason about, and more complex than Go’s usual “simple and explicit” style.

A concrete example from the proposal shows curried functions and a “yield” callback used to drive iteration, including the ability to range backward. While the example is readable in isolation, the broader design is criticized for being “a lot of effing syntax” to express what many consider a basic imperative loop. One proposed equivalence illustrates the transformation: the range body becomes a function that returns a boolean (continue vs stop), and “break” effectively turns into returning false. That rewrite is part of why opponents describe the feature as turning imperative control flow into a functional callback pipeline.

The discussion also splits over iterator implementation strategy—“push” vs “pull.” Russ Cox’s rationale (as referenced in the conversation) favors storing state inside the iterator’s control flow so that cleanup and minimal stack-frame sharing work naturally, and it argues that push iterators are often more convenient to implement. Critics counter that pull-style iterators can be easier to understand and that storing state outside the control flow—such as in a struct with explicit fields—matches how many programmers already model iterators in languages like Rust. That struct-based approach is repeatedly framed as more “one-dimensional,” easier to implement mentally, and less dependent on nested function layers.

Beyond readability, performance and ergonomics concerns surface. Some worry that closures and callbacks—central to the generator-like design—could be a poor fit for Go’s typical performance expectations, even if the feature is mostly used rather than implemented by most developers. Others argue the standard library and third-party packages will shoulder most iterator complexity, so the average Go programmer will mostly consume iterators rather than build them.

The conversation broadens into language-design philosophy: Go is designed for broad adoption, not for researchers or highly specialized language tinkerers. Critics say the iterator design feels out of character for Go’s “grug” audience—people who want straightforward, patchable code rather than clever syntax. Supporters emphasize that iterators unlock useful patterns and align with Go’s evolving ecosystem (generics, reusable slice/map utilities). Still, the loudest takeaway is cultural: even when the design choices are defensible, the resulting syntax and control-flow rewriting make Go 1.23 iterators feel like a departure from what many people think Go should be.