Golang proposal: container/: generic collection types • Hacker News Board

Re: Golang proposal: container/: generic collection types

#41

Post by troupo » Fri, Jul 31, 2026, 9:58 PM UTC

wannabe44 wrote: post #7

silverwind wrote: post #5

Earlier quoted context omitted.

It's sad that such basic stuff took this long. If we're lucky we might even see a `Map` function in our lifetimes.

Map function leads to poor code in Go. Function literals are verbose and inlining is far less agressive. It simply isn't the way of the language. Even python shuns map and filter in favor of comprehensions. A for loop is more readable than the lambda soup.

map functions are very useful for iterating over collections. Most functions iterating over collections are useful, because a lot of the data you're commonly dealing with is collections. And most collections are generic.

> Function literals are verbose and inlining is far less agressive.

> Even python shuns map and filter in favor of comprehensions.

That's the problem of the language design. And Python isn't the best language to turn to for language design

> A for loop is more readable than the lambda soup.

A for loop shoving modified items into a temp variable with append() that is then returned is less readable than a map function transforming data. Too bad Go decided to turn lambdas into unreadable soup.

Re: Golang proposal: container/: generic collection types

#42

Post by troupo » Fri, Jul 31, 2026, 10:01 PM UTC

akiarie wrote: post #28

Honestly the more I see this the less I like Golang. Generics was the worst thing ever added to the language. We're making it easier for library builders and harder for ordinary code to be written.

Here's a quick example of ordinary code that is much easier to write with generics: https://news.ycombinator.com/item?id=49128954

Working on any collection is easier with generics. Working with anything that accesses data in uniform way (APIs, SQL etc.) is easier with generics.

Re: Golang proposal: container/: generic collection types

#43

Post by pstuart » Fri, Jul 31, 2026, 10:01 PM UTC

improgrammer007 wrote: post #31

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.

Core members of the language team (Robert Griesemer and Ian Lance Taylor) argued for generics from the very beginning. The team resisted because they didn't know how to do it without sacrificing speed of compilation.

Rob Pike did a lot of defensive work to deflect it but I'll quote him here on the issue when he said "There are no plans for generics. I said we're going to leave the language; we're done":

"I meant there are no plans for generics. That's not the same as saying we plan not to do generics. It just means we don't have a plan."

You take it as a conspiracy against developers when it's really a small team trying to find their way the best they can.

Re: Golang proposal: container/: generic collection types

#44

Post by throw_m239339 » Fri, Jul 31, 2026, 10:05 PM UTC

znpy wrote: post #19

Looking forward to see G2EE being released as a specification /s

Nothing wrong with J2EE back then if you were building a certain kind of entreprise application. EJBeans actually took care about a lot of business complexity for a n-tier application, it's just that the whole XML crap was absolutely egregious.

Go can barely parse an XML document natively so don't worry about G2EE I'd say...

I'm more worried about what have become of professional Javascript serverside these days, it's just nuts how people have managed to make it as complex as J2EE... Nextjs, Typescript,JSX, React, compilers, transpilers, ... and none of that stuff solves enterprise business logic...

Re: Golang proposal: container/: generic collection types

#45

Post by improgrammer007 » Fri, Jul 31, 2026, 10:05 PM UTC

pstuart wrote: post #43

improgrammer007 wrote: post #31

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.

Core members of the language team (Robert Griesemer and Ian Lance Taylor) argued for generics from the very beginning. The team resisted because they didn't know how to do it without sacrificing speed of compilation. Rob Pike did a lot of defensive work to deflect it but I'll quote him here on the issue when he said "There are no plans for generics. I said we're going to leave the language; we're done": "I meant ther…

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.

Re: Golang proposal: container/: generic collection types

#46

Post by arccy » Fri, Jul 31, 2026, 10:10 PM UTC

nasretdinov wrote: post #17

nasretdinov wrote: post #15

Well, better late than never. Stuff like sets or a typed heap is long overdue. Maybe they'll even add iterator API for database/sql results this decade too (something like my pull request for sqlx https://github.com/jmoiron/sqlx/pull/990 but maybe more polished)

Also having stuff like a concurrency limiter (instead of doing weird var limiter chan struct{} and using it as `limiter <- struct{}{}` and `defer <-limiter`) as a library function in `sync` package would be great too.

there's https://pkg.go.dev/golang.org/x/time/rate ...

Re: Golang proposal: container/: generic collection types

#47

Post by improgrammer007 » Fri, Jul 31, 2026, 10:14 PM UTC

brokencode wrote: post #26

PrimalPower wrote: post #9

Earlier quoted context omitted.

The beauty of go is YAGNI. Language design makes it much harder for people so do stupid and cute things. During my design process if I start realizing that I’m missing maps, More expressive Types, Or more complex polymorphism. I ask myself if I really need those things. If I really do. I move off of go. That’s the beauty of the language. Go does not need more complicated language features because it’s can handle the…

Ok, and what if you realize you want these things a million lines in? Do you still move off of Go? Generic programming isn’t some fancy research language feature like dependent types. It’s just a bare minimum feature in any modern typed language. It’s perplexing that after C# and Java both notably shipped without generics initially then added them later that they decided to ship Go without generics.. only to end up a…

This. One should never pick a language that regresses in terms of features from the get go.

Re: Golang proposal: container/: generic collection types

#48

Post by astonex » Fri, Jul 31, 2026, 10:26 PM UTC

nasretdinov wrote: post #17

nasretdinov wrote: post #15

Well, better late than never. Stuff like sets or a typed heap is long overdue. Maybe they'll even add iterator API for database/sql results this decade too (something like my pull request for sqlx https://github.com/jmoiron/sqlx/pull/990 but maybe more polished)

Also having stuff like a concurrency limiter (instead of doing weird var limiter chan struct{} and using it as `limiter <- struct{}{}` and `defer <-limiter`) as a library function in `sync` package would be great too.

There is actually a way to do this with errgroup provided you can work with func() error signature

https://pkg.go.dev/golang.org/x/sync/errgroup#Group.SetLimit

Re: Golang proposal: container/: generic collection types

#49

Post by tialaramex » Fri, Jul 31, 2026, 10:26 PM UTC

brokencode wrote: post #26

PrimalPower wrote: post #9

Earlier quoted context omitted.

The beauty of go is YAGNI. Language design makes it much harder for people so do stupid and cute things. During my design process if I start realizing that I’m missing maps, More expressive Types, Or more complex polymorphism. I ask myself if I really need those things. If I really do. I move off of go. That’s the beauty of the language. Go does not need more complicated language features because it’s can handle the…

Ok, and what if you realize you want these things a million lines in? Do you still move off of Go? Generic programming isn’t some fancy research language feature like dependent types. It’s just a bare minimum feature in any modern typed language. It’s perplexing that after C# and Java both notably shipped without generics initially then added them later that they decided to ship Go without generics.. only to end up a…

I guess it's possible that C# and Java taught the wrong lesson (you can add this later) and that actually reduced the impetus to ensure Go shipped generics in 1.0

It is also entirely fair to say there's a lot of complexity here and so there's a risk you exceed your complexity budget which for Go as I understand it was very slim. It is a possible a Go 1.0 with more generics doesn't take off because too many people bounce off the extra complexity and so a decade later it's an obscure thing Google made once that has a few fans but not much adoption.

Or that extra complexity means Go 1.0 ships five years later, after Rust 1.0 has given people an appetite for better performance and better safety and its sharpest corners have already been knocked off.

Re: Golang proposal: container/: generic collection types

#50

Post by xtracto » Fri, Jul 31, 2026, 10:29 PM UTC

brokencode wrote: post #26

PrimalPower wrote: post #9

Earlier quoted context omitted.

The beauty of go is YAGNI. Language design makes it much harder for people so do stupid and cute things. During my design process if I start realizing that I’m missing maps, More expressive Types, Or more complex polymorphism. I ask myself if I really need those things. If I really do. I move off of go. That’s the beauty of the language. Go does not need more complicated language features because it’s can handle the…

Ok, and what if you realize you want these things a million lines in? Do you still move off of Go? Generic programming isn’t some fancy research language feature like dependent types. It’s just a bare minimum feature in any modern typed language. It’s perplexing that after C# and Java both notably shipped without generics initially then added them later that they decided to ship Go without generics.. only to end up a…

Maybe at some point it may even get the ternary conditional operator or a proper exception handling syntax.

Those things that Golang defenders say "dont make sense" until it's implemented, then 'it always made sense" and of course it's a good idea.