Has Go Started Moving Away from Its Original Philosophy?
One of the reasons I originally liked Go was its philosophy: there was usually one obvious way to solve a problem. That simplicity made codebases easier to read, easier to review, and easier for new developers to understand.
Generics solved a real problem. Before Go 1.18, it was common to duplicate code for different types or fall back to interface{}. In that sense, generics were a worthwhile addition.
However, I feel the feature is intentionally conservative. For example, Go still doesn't support generic methods, which limits some abstractions that are common in other languages. While I understand the design rationale, it sometimes feels like Go added generics without embracing the full set of patterns they enable.
The new iterator support leaves me with a similar feeling. Now there are multiple ways to express iteration depending on the API. None of them are inherently bad, but one of Go's original strengths was minimizing the number of equally valid approaches. As the language grows, that consistency becomes harder to preserve.
My concern isn't that these features are poorly designed. My concern is that each new feature moves Go a little further away from the minimal language that originally attracted many of its users.
Sometimes it feels like Go is trying to borrow ideas from languages like Rust or TypeScript while intentionally stopping short of matching their expressive power. The result is a language that is becoming more capable, but also more complex.
I still enjoy writing Go, but I sometimes wonder whether the project would have benefited more from doubling down on performance, tooling, diagnostics, and runtime improvements rather than expanding the language itself.
I'm curious how others see this. Has Go found the right balance between simplicity and expressiveness, or do you think it's gradually drifting away from its original philosophy?
