By ByteBot
On July 28, the Go Collections Working Group — seven engineers from Google’s Go team, including Robert Griesemer, Alan Donovan, and Ian Lance Taylor — opened proposal #80590 targeting Go 1.28. It covers native generic sets, ordered maps, and a redesigned heap for the standard library. If the proposal lands, Go 1.28 ends a decade-long workaround: the map[T]struct{} pattern finally gets a proper replacement. The HN thread hit 432 points within days, and Go Weekly dedicated its Issue #612 to the proposal.
Go 1.28 Generic Collection Types, Explained
The proposal introduces five concrete additions. set.Set[T] is the one most developers have wanted since Go 1.0. It is transparently backed by map[T]struct{}, so performance intuitions stay intact, but it ships with Union, Intersection, Difference, and SymmetricDifference out of the box. Mutation methods return whether the size changed — no more redundant lookups. For non-comparable types like slices and maps, hash.Set[T] fills the gap with a user-supplied hash function.
The before/after contrast is blunt:
// BEFORE: current Go "set" idiom
type StringSet map[string]struct{}
func (s StringSet) Add(v string) { s[v] = struct{}{} }
func (s StringSet) Has(v string) bool { _, ok := s[v]; return ok }
// Union requires a manual loop — every time
// AFTER: proposed set.Set
a := set.New("alice", "bob")
b := set.New("bob", "carol")
union := a.Union(b) // {alice, bob, carol}
inter := a.Intersect(b) // {bob}
Beyond sets, ordered.Map[K,V] adds a balanced binary tree map for sorted key iteration — something Go has lacked entirely. hash.Map[K,V] handles custom-hashed non-comparable keys. And heap/v2.Heap replaces the current container/heap package, which requires implementing a five-method interface on your own slice type and is widely considered one of Go’s worst ergonomic mistakes.
Why It Took Four Years After Generics
Go shipped generics in 1.18 (2022). The obvious question is why generic collections didn’t follow immediately. The working group’s answer is in the proposal text: they needed both generics (Go 1.18) and range-over iterators (Go 1.23, 2024) before library types could achieve comparable ergonomics to built-in types. Without iterators, a set you couldn’t range over naturally would have felt second-class.
This reframes the Go team’s pace. The four-year gap wasn’t neglect — it was the team deliberately waiting until the full language foundation was in place. The same philosophy produced Java’s Project Valhalla: long waits, then a complete answer. Go just moves slower by design, and in this case the argument holds up.
Third-Party Libraries That Lose Their Reason to Exist
deckarep/golang-set has roughly 4,000 GitHub stars and counts Docker, 1Password, Ethereum, and Hashicorp among its users. It becomes a legacy dependency for new projects the moment set.Set lands in the stdlib. Similarly, ordered map libraries like wk8/go-ordered-map become redundant for sorted-key use cases. The existing container/heap package will be superseded by heap/v2 — and not a moment too soon.
For existing codebases, the migration will be mechanical. Since set.Set[T] is backed by the same map[T]struct{} internally, switching is a find-and-replace exercise, not an architectural overhaul. The proposal also includes container/mapset helper functions for code that stays on the existing map-based pattern.
Related: etcd v3.7: RangeStream and What Kubernetes Teams Must Do — another Go ecosystem update with migration requirements
The HN Debate Worth Reading
The community isn’t unanimously cheering. A significant thread argues the naming is “too mathematical” — Union and Intersection belong in a math textbook, not a systems language. Others counter that set theory terminology is exactly correct here and anything else would be confusing. A separate thread worries Go is “becoming the next C++/Java” by adding collections complexity. The most upvoted response: “22 years late, but better late than never.”
The real tension is Go’s identity. The language built its reputation on deliberate omission — no generics for 13 years, no ordered maps, no sets. Now it has all three incoming. The community appears broadly welcoming, but the debate reflects a genuine question about what Go is supposed to be going forward.
Key Takeaways
- Go’s Collections Working Group opened proposal #80590 on July 28, targeting Go 1.28 with five new generic types: set.Set, hash.Set, hash.Map, ordered.Map, and heap/v2
- The four-year gap between generics (Go 1.18) and this proposal was deliberate — range-over iterators (Go 1.23) were the missing ergonomic prerequisite
- Third-party libraries including deckarep/golang-set and wk8/go-ordered-map become legacy dependencies for new projects once Go 1.28 ships
- Go 1.28 targets approximately February 2027 based on Go’s six-month release cadence — the proposal is still in community review, not yet merged
- Migration for existing code will be mechanical: set.Set is backed by the same map[T]struct{} internally, making the switch low-risk
