Go Gets Generic Collections, Slowly and Awkwardly
A Go proposal to add generic collection types to a new container/ package is moving forward, covering sets, typed heaps, and similar structures that Go has always lacked. The comments were appreciative but pointed: Go is reinventing things that other languages figured out decades ago, and the generics implementation added in Go 1.18 doesn't make it feel natural.
One commenter referenced Guy Steele's 'Growing a Language' talk from 1998 to make the point that Go is rediscovering first principles at a painful pace. Another noted that basic iterator support for database/sql results still doesn't exist despite years of proposals.
The counterpoint from Go defenders: the language's conservatism is the point. It ships reliable, boring code, and adding things slowly means they stay coherent. But the frustration in the thread is real, and it's coming from people who use Go daily and want it to catch up on ergonomics without becoming a different language.
So what?
If you're choosing a backend language for a new service today, Go's ecosystem gaps are real friction. The generics situation is improving but the standard library is still catching up. This matters for library authors especially: if you're building Go tooling, expect users to want typed collections and clean iterator APIs sooner rather than later.