--- title: Golang proposal: container/: generic collection types description: The Go Collections working group (formed late 2025) has published a proposal for adding generic collection types to the Go standard library in Go 1.28. The... canonical: https://daily.dev/posts/golang-proposal-container-generic-collection-types-hmnqb6rbk twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Golang proposal: container/: generic collection types | daily.dev og:description: The Go Collections working group (formed late 2025) has published a proposal for adding generic collection types to the Go standard library in Go 1.28. The... og:url: https://daily.dev/posts/golang-proposal-container-generic-collection-types-hmnqb6rbk og:image: https://api.daily.dev/og/posts/hMnQB6rBk.png og:image:alt: Golang proposal: container/: generic collection types og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Golang proposal: container/: generic collection types **[Hacker News](https://daily.dev/sources/hn)** · 12 min read · 4 upvotes · 0 comments ## Summary The Go Collections working group (formed late 2025) has published a proposal for adding generic collection types to the Go standard library in Go 1.28. The umbrella issue covers several concrete proposals: container/hash.Map and container/hash.Set (hash-based, supporting custom hash functions), container/set.Set (comparable-element sets backed by map[T]struct{}), container/mapset (helper functions for legacy map-based sets), container/ordered.Map (balanced binary tree ordered map), and container/heap/v2.Heap (generic heap replacing the existing one). The proposal also introduces unexported abstract constraint interfaces (Collection, Set, Map) using F-bounded polymorphism to enable generic helper functions across collection types. Community discussion covers naming consistency across packages, method naming conventions (Get vs At, DeleteAll semantics), whether AbstractMap should extend AbstractCollection, and the tradeoffs of returning mutation-changed flags from methods. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 1 discussion and 68 comments across hackernews (as of 2026-07-31). **TL;DR:** The community is divided: some welcome Go's gradual addition of generic stdlib utilities as pragmatic progress, while others criticize the slow pace, the awkward fit of generics into Go's original design, and the years of wasted effort writing workarounds. **Sentiment:** 25% positive · 45% mixed · 30% skeptical **The case for** - Long-overdue stdlib additions like typed sets, heaps, and concurrency helpers will reduce boilerplate and workarounds. - The Go team's cautious, deliberate approach to language evolution is appreciated by pragmatic users who value stability. - Burying generic complexity behind clean stdlib interfaces is seen as a net improvement even by generics skeptics. **The pushback** - Pre-1.0 design decisions (e.g., no methods on external types) now create objective limitations that generics cannot fully fix. - Years of defending the absence of generics led to massive amounts of workaround code and tech debt that now needs revisiting. - Iterators introduced as part of the generics effort have sharp edges, including runtime panics for logic bugs that for-loops would have caught at compile time. - Some feel Go is slowly losing its simplicity and uniqueness without gaining enough in return to justify the complexity cost. - The 'everything is a trade-off' defense is criticized as only valid if the language is on the Pareto frontier, which commenters argue it is not. **By community** - hackernews (mixed): Commenters are split between pragmatic appreciation for Go's careful evolution and frustration over years of avoidable tech debt and design limitations exposed by late-added generics. **Hottest debate:** Whether the Go team's long resistance to generics was principled caution or a costly mistake that wasted years of developer effort across the ecosystem. **Open questions** - Will Go ever address the inability to define methods on external types, which limits generic programming? - Is a Go 2.0 with more foundational generic support realistic, or is backward compatibility a permanent constraint? - Will the standard library be fully refactored to leverage generics, and how long will that take? **Highlights** > On the other hand, design decisions made under one set of constraints can become problematic when you add new features that don't play as well with earlier design decisions. For a concrete example, the fact you cannot define custom methods for external types in Go (a pre-1.0 design decision) means that you cannot write proper compile-time generic code to deal with some generic wrapping type (dumb example -- getting a sum of the perimeters of a generic set of shapes in an externally-defined collection type) -- you are forced to work around it with runtime type-switching. There are all sorts of arguments you can make about simplicity but this is an objective shortcoming of Go that is directly caused by generics being added to Go long post 1.0. My take on this is that despite selfishly wanting more from Go for many years myself, adding more stuff to Go at this late stage is just slowly chipping away at Go's uniqueness with features that make a large number of people using them unhappy. (For example, while they make some APIs nicer, iterators turn a basic logic bug that is impossible with for loops -- forgetting to stop iterating when the loop has a "break" -- into a runtime panic. And they really suck to compose.) > — [cyphar on hackernews · 3 comments](https://news.ycombinator.com/item?id=49128029) > First they said they won't add generics. They violently defended that decision. Developers bent over backwards to make it work without generics. Some even wrote long blog posts defending Rob Pike's decision. Some wrote posts arguing against it. Now the Golang team adds them. Why waste so much developer time? It's not a few months. It's several years. This industry is seriously a clown show tbh. > — [improgrammer007 on hackernews · 4 comments](https://news.ycombinator.com/item?id=49128847) > It's an utter waste of time for developers, business, everyone. Millions of lines of Go code have been written without generics. Libraries have been written. Support, maintenance, cost, etc. This is why one shouldn't pick languages that regress in features from the get go. Now developers will waste time migrating the code to stdlib. This is not solving problems. This is doing tech for the sake of doing tech. Wasting everyone's time. Remember that code is not the deliverable. > — [improgrammer007 on hackernews · 1 comments](https://news.ycombinator.com/item?id=49129079) > "Everything is a trade-off" assumes you're on the Pareto frontier. Go is... very much not on the Pareto frontier of programming language design. > — [tikhonj on hackernews · 3 comments](https://news.ycombinator.com/item?id=49128238) > Reminds me of when Apple finally moved the iPhone to USB-C… they defended lightning for the longest time, but then when when they finally did the switch, all I could think was “the last N years [0] of lightning accessories I’ve bought are now ewaste”… once it became clear USB-C was going to be the future, every year they weren’t using it was another year of future ewaste building up. Every year go didn’t have generics was another year of workarounds and tech debt building up that would have otherwise been able to be written the right way from the start. Unlike ewaste though, it’s probably impossible to quantify. [0] I’d probably peg N as the years between when they gave MacBooks USB-C ports for charging, up until the iPhone got them. It’s clear Apple knew they were gonna need to move to it eventually… every year in that period represents a year of lightning cables people bought that could have been still-useful USB-C cables today. > — [ninkendo on hackernews](https://news.ycombinator.com/item?id=49129304) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49127031) · 55 points · 68 comments ## Similar posts on daily.dev - [Issue \#612: A plan to bring generic collections to Go 1.28 — Go Weekly](https://daily.dev/posts/issue-612-a-plan-to-bring-generic-collections-to-go-1-28-go-weekly-nqh8z57m0) · Golang Weekly · 8 upvotes · 0 comments --- Tags: [#golang](https://daily.dev/tags/golang), [#data-structures](https://daily.dev/tags/data-structures) [View this post on daily.dev](https://daily.dev/posts/golang-proposal-container-generic-collection-types-hmnqb6rbk) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Golang proposal: container/: generic collection types","url":"https://daily.dev/posts/golang-proposal-container-generic-collection-types-hmnqb6rbk","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/golang-proposal-container-generic-collection-types-hmnqb6rbk"},"datePublished":"2026-07-31T20:41:09.283Z","dateModified":"2026-07-31T22:55:02.516Z","description":"The Go Collections working group (formed late 2025) has published a proposal for adding generic collection types to the Go standard library in Go 1.28. The...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/2eaff06183df26534793d50fb8474037?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/2eaff06183df26534793d50fb8474037?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/golang-proposal-container-generic-collection-types-hmnqb6rbk","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"golang,data-structures","timeRequired":"PT12M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Golang proposal: container/: generic collection types"}]} ```