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

Re: Golang proposal: container/: generic collection types

#81

Post by [deleted] » Sat, Aug 01, 2026, 1:58 AM UTC

DarkNova6 wrote: post #75

somekyle2 wrote: post #66

Earlier quoted context omitted.

I respect "we're going to try not to add features until we have to and have a plan that we like" as an approach to a practical language, vs "we're going to plan to support everything normal modern languages have". It isn't the best approach to language design in theory, but they did try to build a language that isn't impossible to change, and to be fair the mix of language features they chose didn't have any good mor…

I totally get that. Java is my favorite language for exactly that reason. They are a deliberate "late mover language" and adopt what other languages have proven right. But looking at how adamant Go used to be on the whole "No Generics" stance and the path and the troubles they are having... it all seemes so preventable?

[deleted]

Re: Golang proposal: container/: generic collection types

#82

Post by rattlesnakedave » Sat, Aug 01, 2026, 2:01 AM UTC

TheDong wrote: post #74

nasretdinov wrote: post #18

Earlier quoted context omitted.

Why isn't it a good fit? The design prioritises readability of code that uses generics vs writing generic code (which is in line with the overall language philosophy). It also does it in a way that doesn't impact compilation speed or add too much complexity, which is also in line with the language philosophy. If you don't like the fact that not all of standard library has been refactored to support the new language f…

I agree it's not a good fit. Go is a language built for people who don't wish to learn any math or CS theory, for people who don't wish to be "computer scientists" but rather "grug-brained programmers". The new datatypes will mean having to read things like "sz := sx.Union(sy)", and the union operation between sets is too math-like, and thus makes it less readable. "Advanced" data-types, like sets and heaps, only mak…

some of us that have to work with people like you are happy that you're constrained by Go.

Re: Golang proposal: container/: generic collection types

#83

Post by win311fwg » Sat, Aug 01, 2026, 2:08 AM UTC

DarkNova6 wrote: post #75

somekyle2 wrote: post #66

Earlier quoted context omitted.

I respect "we're going to try not to add features until we have to and have a plan that we like" as an approach to a practical language, vs "we're going to plan to support everything normal modern languages have". It isn't the best approach to language design in theory, but they did try to build a language that isn't impossible to change, and to be fair the mix of language features they chose didn't have any good mor…

I totally get that. Java is my favorite language for exactly that reason. They are a deliberate "late mover language" and adopt what other languages have proven right. But looking at how adamant Go used to be on the whole "No Generics" stance and the path and the troubles they are having... it all seemes so preventable?

Does it? It was only preventable by not releasing Go, which isn't exactly the greatest of solutions.

As you know from when Go was first broadcast to the world, they hadn't figured out how to make generics fit[1]. It is not like they weren't trying. Ian Lance Taylor is regarded for beginning work on generics before anyone outside of Google had even heard of Go. "In short: not yet"

What was surprising is that after Go was released as an open source project, nobody across the whole wide world ever came up with a workable solution. You can sense the optimism in that original announcement that later turned to "Go might never get generics" dispair. As you'll recall, it finally took convincing Philip Wadler (of Haskell and Java generics fame) to help. Without that lucky break, which almost certainly never would have happened if Go was still some basement project used by nobody, Go probably still wouldn't have generics.

[1] https://youtu.be/rKnDgT73v8s?t=3267

Re: Golang proposal: container/: generic collection types

#84

Post by roundwego » Sat, Aug 01, 2026, 3:12 AM UTC

A bit too late frankly. The snobbish arrogance didn’t help.

Re: Golang proposal: container/: generic collection types

#85

Post by cyphar » Sat, Aug 01, 2026, 3:19 AM UTC

aatd86 wrote: post #22

cyphar wrote: post #8

Earlier quoted context omitted.

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…

__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 s…

In Rust this is solved by defining a local trait and methods implemented for a trait are only available if the trait is imported. This is in contrast to Go where methods are not namespaced at all. But there are almost certainly many other ways of solving the problem.

I was a little surprised how often I ran into this issue when using libraries that started defining structures as generic containers.

Re: Golang proposal: container/: generic collection types

#86

Post by ako » Sat, Aug 01, 2026, 3:27 AM UTC

farfatched wrote: post #80

DarkNova6 wrote: post #75

Earlier quoted context omitted.

I totally get that. Java is my favorite language for exactly that reason. They are a deliberate "late mover language" and adopt what other languages have proven right. But looking at how adamant Go used to be on the whole "No Generics" stance and the path and the troubles they are having... it all seemes so preventable?

I think it was. Go without generics was ok. I say that as a fan of generics in other languages. There is room for languages with simpler feature sets. It takes a strong leader (and the good and bad that comes with that) to continue to deny features. Go had that. Does it still? (I genuinely don't know.) I'm not sure what Go's value proposition is now. Developers can't pick it up in a week, as it used to be. Maybe that…

Go value proposition for me, when developing with Claude code: 1) fast compilation times, faster iterations, 2) user friendly to install, one single binary per platform, 3) feels safer than JavaScript/typescript, which have too many npm vulnerabilities. Go comes with more functionality included, less need to use 3rd party libraries.

Re: Golang proposal: container/: generic collection types

#87

Post by smithcoin » Sat, Aug 01, 2026, 3:51 AM UTC

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)

You’d have a better chance of getting your PR accepted into https://github.com/Vinovest/sqlx

Re: Golang proposal: container/: generic collection types

#88

Post by wlamartin » Sat, Aug 01, 2026, 4:18 AM UTC

TheDong wrote: post #78

wannabe44 wrote: post #7

Earlier quoted context omitted.

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.

> A for loop is more readable than the lambda soup. Let's assume you have a slice of strings you want to uppercase. Which of the following is more readable? uppercased := slices.Map(inputSlice, strings.ToUpper) // or uppercased := make([]string, 0, len(inputSlice)) for _, s := range inputSlice { uppercased = append(uppercased, strings.ToUpper(s)) } Let's say you want to parse a bunch of user-given inputs into duratio…

I think in a language designed around FP ergonomics and expectations there's a lot to like about it.

In your second example, as a retrofit, I find myself asking "when does MapErr stop consuming the input list?", "which error gets returned if multiple errors could be returned?", "is it a errors.Joim situation", "if there are multiple errors how do I map them to the failed elements in parsed", "if I did want each parse to have either success or fail (think Result type) how would I represent this generically in a language that favours multiple return types"

There's a lot going on with that example that a for loop makes explicit and flexible for other choices.

Re: Golang proposal: container/: generic collection types

#89

Post by kokada » Sat, Aug 01, 2026, 4:26 AM UTC

jppittma wrote: post #57

improgrammer007 wrote: post #45

Earlier quoted context omitted.

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…

Claude will migrate your whole repo in an hour.

I assume they will eventually add those to `go fix` too, so you don't even need Claude for the most basic refactors (the more complex ones, sure).

Re: Golang proposal: container/: generic collection types

#90

Post by kokada » Sat, Aug 01, 2026, 4:32 AM UTC

ninkendo wrote: post #52

improgrammer007 wrote: post #33

Earlier quoted context omitted.

Nothing is wrong. What was wrong before when they vehemently argued against adding it? Is that design principle/core value lost now?

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 generic…

Technical debt, sure. But you could argue the same for any new feature added to a programming language, without having X you will need to workaround with Y, generating technical debt.

To be clear, I was one of those people that only started to use Go after generics. But for most of my projects, generics is less than 1% of the code base, so it is not like lack of generics was a huge issue. I think it is more of a problem for libraries in general.