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

Re: Golang proposal: container/: generic collection types

#141

Post by cyphar » Sat, Aug 01, 2026, 12:12 PM UTC

Hendrikto wrote: post #131

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…

> the fact you cannot define custom methods for external types in Go Just wrap them. The external type is theirs. Make your own wrapper and do whatever you like with it. People want every language to adapt to them, instead of adapting themselves to the language.

That is the classic answer for how to do that in pre-generics Go. It doesn't solve the problem I mentioned.

Re: Golang proposal: container/: generic collection types

#142

Post by elktown » Sat, Aug 01, 2026, 12:14 PM UTC

DarkNova6 wrote: post #62

Step by step, Go is now learning the hard lessons every other language has learned over the last 20 years. The fact that despite their best efforts, their propositions look like everone else is a surprisingly refreshing affirmation of status quo.

Or it’s just people with different opinions that took charge.

I find it funny reading sometimes how my country learned to conform on something that was previously a bit unique and people are like ”yeah, even they figured out it doesn’t work!”. No, you dingus, the people that wanted to conform were just elected. It worked perfectly fine otherwise.

Re: Golang proposal: container/: generic collection types

#143

Post by ncruces » Sat, Aug 01, 2026, 12:26 PM UTC

dgunay wrote: post #125

It's cool that they're doing this but with iterators and soon in 1.27 generic method parameters, you can already DIY most of this with little effort. I've got iterators at work for nearly everything I could want, small libraries for extra mapping, filtering etc operations, and with agents going back and actually refactoring old code to use them is easier than ever.

Well adding the language features is a prerequisite to making these libraries possible.

Re: Golang proposal: container/: generic collection types

#144

Post by sethammons » Sat, Aug 01, 2026, 12:32 PM UTC

ndriscoll wrote: post #140

win311fwg wrote: post #118

Earlier quoted context omitted.

Presumably you are referring to https://github.com/golang/go/discussions/71460 ? While the proposed slightly reduced the token count, saving the average typist approximately 1 second of time if they don't have an autocomplete editor that types it for them, it doesn't change anything about the mental model where the real time is actually spent, so is it really sane? Worse, it is dependent on the error type, but errors…

Reducing syntactic noise is about legibility, not writing ease. The error boilerplate as it exists interrupts the actual logic and makes most of your code read as sad paths that might never execute. Of course if you want something less specific to errors, we already have do-notation as an excellent example to look at. And you can't say that's more complex for users than what they did with iterators.

> The error boilerplate as it exists interrupts the actual logic and makes most of your code read as sad paths that might never execute.

Yes! You have to think through and account for edge cases. "Might not" is the same as "might." Those branches might execute.

I have been on many projects over 25 years of software development. Projects that take error handling seriously tend to be better all around. Happy-path coding is naive.

Re: Golang proposal: container/: generic collection types

#145

Post by ndriscoll » Sat, Aug 01, 2026, 12:39 PM UTC

sethammons wrote: post #144

ndriscoll wrote: post #140

Earlier quoted context omitted.

Reducing syntactic noise is about legibility, not writing ease. The error boilerplate as it exists interrupts the actual logic and makes most of your code read as sad paths that might never execute. Of course if you want something less specific to errors, we already have do-notation as an excellent example to look at. And you can't say that's more complex for users than what they did with iterators.

> The error boilerplate as it exists interrupts the actual logic and makes most of your code read as sad paths that might never execute. Yes! You have to think through and account for edge cases. "Might not" is the same as "might." Those branches might execute. I have been on many projects over 25 years of software development. Projects that take error handling seriously tend to be better all around. Happy-path codin…

In the overwhelming majority of cases, you want to trivially send the error up the stack to be handled, so you don't want to incur the noise in the middle of your business logic (and indeed doing so obscures the times when error handling is non-trivial!). e.g. Scala handles all error cases with compile time checking (in fact it tends to take error handling much more seriously), but you don't have to write (or read) the trivial case.

Re: Golang proposal: container/: generic collection types

#146

Post by kbolino » Sat, Aug 01, 2026, 1:02 PM UTC

ndriscoll wrote: post #145

sethammons wrote: post #144

Earlier quoted context omitted.

> The error boilerplate as it exists interrupts the actual logic and makes most of your code read as sad paths that might never execute. Yes! You have to think through and account for edge cases. "Might not" is the same as "might." Those branches might execute. I have been on many projects over 25 years of software development. Projects that take error handling seriously tend to be better all around. Happy-path codin…

In the overwhelming majority of cases, you want to trivially send the error up the stack to be handled, so you don't want to incur the noise in the middle of your business logic (and indeed doing so obscures the times when error handling is non-trivial!). e.g. Scala handles all error cases with compile time checking (in fact it tends to take error handling much more seriously), but you don't have to write (or read) t…

> In the overwhelming majority of cases, you want to trivially send the error up the stack to be handled

Maybe so, but for JVM languages, this "trivially" includes a stack trace. Go doesn't offer that for normal errors and there was no clear path to getting it. The need for contextual clues when debugging, and the community and then stdlib settling on error-wrapping as the way to do it, makes "simply return err" not a sane default anymore.

Re: Golang proposal: container/: generic collection types

#147

Post by Pooge » Sat, Aug 01, 2026, 1:25 PM UTC

tzone wrote: post #134

kamma4434 wrote: post #98

Welcome to Java, where Collections are the bread and butter of every programmer since 1998. While you are at it, I humbly suggest to add composable streams too, that we had in 2014, and that make working with collections way more pleasant. (Jokes aside, in Java it is very nice that you can start with a generic ArrayList and turn it into a linked list with one single keyword change and no code needs changing, or that…

People use Go vs Java not because of the language differences but because of massive improvement that GO runtime is compared to JVM. It is crazy that people still don't understand why JVM sucks, and why GO's approach to minimize GC pause latency is far superior design decision compared to whatever JVM has been trying to do with its GC iterations for god knows how many years with gazzillion different variants that all…

I'm the biggest fanboy of Go, but since Java 25 the default garbage collector (ZGC) is very similar to Go's.

Re: Golang proposal: container/: generic collection types

#148

Post by JamesSwift » Sat, Aug 01, 2026, 1:44 PM UTC

hwc wrote: post #136

DarkNova6 wrote: post #62

Step by step, Go is now learning the hard lessons every other language has learned over the last 20 years. The fact that despite their best efforts, their propositions look like everone else is a surprisingly refreshing affirmation of status quo.

On the other hand, I've found that for every real-world application I've written in Go, I have not found myself missing any of the containers C++ has had since 2003. I didn't really ever need generics either. I only use them to make it to make it clear which functions don't rely on specific properties of the type they operate on. Yes, there are occasionally really good reasons to use an ordered map or a priority queu…

Most generics code is for library authors. Having generics allows you to write ergonomic algorithms for eg channels instead of forcing every single app developer to reinvent the wheel and run into the same footguns

Re: Golang proposal: container/: generic collection types

#149

Post by pjmlp » Sat, Aug 01, 2026, 1:49 PM UTC

inigyou wrote: post #128

pjmlp wrote: post #109

Earlier quoted context omitted.

Turns out programming languages are complex for a reason.

But diversity is good. If I want C++, I already know where to find it.

The fallacy of "simple" languages is not understanding the history of programming languages, why and how they grow with the community, assuming they get any adoption at all.

No one among the folks that created Scheme or C, would assert R7RS or C23 are that simple.

Re: Golang proposal: container/: generic collection types

#150

Post by pjmlp » Sat, Aug 01, 2026, 1:55 PM UTC

win311fwg wrote: post #120

pjmlp wrote: post #117

Earlier quoted context omitted.

Go is basically a mix between Oberon-2 and Limbo, which we all know where they landed on the adoption curve. Without the adoption success of Docker and Kubernetes adding wind to Go's sails, Go would have landed on the island. They were not lacking in skills, rather politics, and there is a public talk from Rob Pike where he mentions even the Go 1.18 generics would not have landed if it was for him.

> Go is basically a mix between Oberon-2 and Limbo, which we all know where they landed on the adoption curve. Exactly. You might say that Wirth, Mössenböck, and Winterbottom had some programming language chops, bringing some new ideas to the world, which is in line with the observation that those with programming language skills end up creating languages nobody uses. In fairness, Pike was involved in Limbo, but his…

Really wearing the team's t-shirt there, Go was barely proven on the language adoption battlefield when Go heads preverted the direction Docker and Kubernetes were going, it wasn't even 1.0.

Lots of languages are full of dead projects that never gained notoriety.

In fact, YouTube downloader which is another "success" only happened, because once again, it was a gopher that forced a RIG, it was working perfectly fine.