Is Go Straying from Its Original Simplicity? A Reddit Thread Uncovers the Community’s Deep Divide

A Reddit post titled “Is Go already moving away from its original philosophy?” sparked a heated debate within the Go community about whether recent language features—generics (Go 1.18) and iterators (Go 1.23)—are eroding the language’s core principle of extreme simplicity.

Original Concern

The poster argued that each new feature pushes Go farther from the “single obvious way to write code” ideal that made the language easy to read and learn.

Supporters’ View

Supporters contend that Go was “too simple” in its early days, lacking essential capabilities. They see generics and iterators as a justified “pay‑back” that fills long‑standing gaps. One user highlighted that generic methods will land in Go 1.27, and another praised the iterator push model as a valuable abstraction, arguing that the language remains conservative compared to Rust or TypeScript.

Opponents’ View

Opponents warn that every added feature raises the learning curve for new contributors and threatens Go’s original promise of rapid onboarding. They cite concrete issues such as the push‑based iterator design, which prevents simultaneous iteration (e.g., implementing a zip() ‑style function) without extra goroutines, and the added complexity of iter.Pull requiring a dedicated goroutine and persistent call stack.

“I’m not worried that the features are badly designed; I’m worried that each new feature pushes Go farther from the minimal language that attracted many users.”

Technical Deep‑Dive

Several participants dissected the practical impact of generics. One user claimed that for most projects generic code is a “code smell” and that they rarely write generic code themselves, preferring interfaces or any conversions. Another argued that generics can reduce duplication but are not a silver bullet, especially in HTTP/gRPC boundaries where converting between any and concrete types adds noise.

Regarding iterators, a user demonstrated converting a push‑based iterator to a pull‑based one with the following code:

func Zip[T, R any](i1 iter.Seq[T], i2 iter.Seq[R]) iter.Seq2[T, R] {
    return func(yield func(v1 T, v2 R) bool) {
        nextT, stopT := iter.Pull(i1)
        nextR, stopR := iter.Pull(i2)
        defer stopT()
        defer stopR()
        for {
            v1, ok1 := nextT()
            v2, ok2 := nextR()
            if !ok1 || !ok2 { break }
            if !yield(v1, v2) { break }
        }
    }
}

Critics pointed out that iter.Pull is complex and incurs goroutine overhead, whereas C++ iterators can be inlined and are cheaper.

AI‑Assisted Coding Angle

One commenter noted that large language models still struggle to generate code using the new iterator API because training data for these features is sparse, suggesting that AI will not replace developers in the short term.

Conclusion

The discussion ended without a clear winner. Both sides agree that simplicity is a core value, but differ on whether generics and iterators protect that value by filling missing pieces or undermine it by adding complexity. The community sees the debate as an ongoing tension in Go’s evolution, with the ultimate judgment pending future language versions.