Go 1.
for loop to rule them all. But after Go 1.23 and the subsequent 1.26 updates, that agreement feels broken. We've traded straightforward loops for iter.Seq and iter.Seq2, and suddenly every junior dev needs to understand push vs. pull iterators and yield callbacks just to iterate over a collection.The standard library shift
It's one thing when a third-party library gets "clever," but it's another when the standard library does. In Go 1.26, the reflect package was overhauled. Instead of the old NumField and Field(i) pattern, we now have iterator versions for Type.Fields and Value.Methods. Whether you enjoy this functional style or hate it, you can't escape it anymore. It's in the imports, the snippets, and the PRs I'm reviewing. The community is split right down the middle: half the people call it "elegant," and the other half feel the language's identity is being erased.
Performance takes a hit for aesthetics
The most frustrating part is that this "expressive power" isn't free. If you look at the benchmarks, ranging over an iterator is consistently slower than directly ranging over a slice or a map. We're paying a performance tax for an abstraction that doesn't actually make the code faster—it just makes it look "modern." Multiple studies have shown that custom iterators rarely outperform classical data structures. We basically traded raw speed for aesthetic preference.
The "Rust Envy" pipeline
I'm seeing a trend where Go is essentially speedrunning Rust's complexity. Take a look at Iterium, which brings Python-style itertools and Rust-like lazy pipelines (Map, Filter, TakeWhile) to Go. Sure, it's technically fast—streaming 10 million values through a pipeline in 0.06 seconds on Go 1.26.2 is impressive. But why are we rebuilding Rust inside Go? Many of us switched to Go specifically to avoid the cognitive overhead of Rust, yet here we are reconstructing those same complex patterns.
Hiding complexity isn't the same as removing it
There is a huge difference between "concise" and "clear." When you hide logic behind a yield callback, you aren't removing complexity; you're just moving it to a place where it's harder to reason about. If you're building an AI workflow or a complex LLM agent backend, you want your core logic to be transparent, not buried under layers of functional abstractions.
For anyone wanting a practical tutorial on how to keep their code clean despite these changes, I'd suggest sticking to the classical approach unless the iterator provides a massive architectural win. Go's superpower was always readability over cleverness.
My current take on the trade-offs:
- Readability: Dropped. Logic is now fragmented across callbacks.
- Performance: Slower. Abstractions add overhead compared to slices.
- Developer Velocity: Mixed. Faster to write "clever" lines, slower to debug.
- Cognitive Load: Increased. Now we have to track iterator states.