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

Re: Golang proposal: container/: generic collection types

#151

Post by hashmash » Sat, Aug 01, 2026, 2:09 PM UTC

Pooge wrote: post #147

tzone wrote: post #134

Earlier quoted context omitted.

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.

Low pause collectors like ZGC and Shenandoah must be enabled explicitly. G1 is still the default.

It should also be noted that the low pause Azul C4 collector was available in 2010, but it was a commercial product.

Re: Golang proposal: container/: generic collection types

#152

Post by Pooge » Sat, Aug 01, 2026, 2:23 PM UTC

hashmash wrote: post #151

Pooge wrote: post #147

Earlier quoted context omitted.

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

Low pause collectors like ZGC and Shenandoah must be enabled explicitly. G1 is still the default. It should also be noted that the low pause Azul C4 collector was available in 2010, but it was a commercial product.

You're right; apologies! I set the JVM flag quite some time ago, haha.

Re: Golang proposal: container/: generic collection types

#153

Post by win311fwg » Sat, Aug 01, 2026, 2:55 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.

> Reducing syntactic noise is about legibility, not writing ease.

Exactly, which said proposal does nothing to improve upon. Despite the reduction in characters it looks exactly the same as the traditional way, offering no way to improve how one think about errors. That proposal was clearly thrown out there just to try and appease the "Go doesn't have error handling" crowd without any thought into what would actually make the language better. The goal may be noble, but that particular proposal was rightfully abandoned.

> The error boilerplate as it exists interrupts the actual logic

Huh? No matter what logic you throw at the problem, there is no escaping that error handling is part of the actual logic. And it is, by far, the most important piece of the logic. Engineering is all about dealing with failure modes.

I'll grant you that there is a category of problems known as scripting tasks where error states simply can mean letting the program crash and allowing the user to clean up afterwards, but Go is clearly not trying to be a scripting language.

Re: Golang proposal: container/: generic collection types

#154

Post by brokencode » Sat, Aug 01, 2026, 2:58 PM UTC

inigyou wrote: post #139

brokencode wrote: post #71

Earlier quoted context omitted.

Well here’s the thing on generics. Go always had generics since the very beginning. It’s just that only certain built-in types had them. Slices, maps, and channels all were generic from day one. Same with functions like append, copy, etc. Your criticism makes no sense unless you think Go shouldn’t have had generics from the start, which it did.

By that logic C has generics because pointers are a generic type - you can have a pointer to any type you want.

Sure, lots of languages have some level of parametric type support.

This is just basic programming stuff and not limited to esoteric research languages.

Yet so many in the Go community treated it as some kind of language-ruining complexity.

Re: Golang proposal: container/: generic collection types

#155

Post by win311fwg » Sat, Aug 01, 2026, 2:59 PM UTC

kbolino wrote: post #146

ndriscoll wrote: post #145

Earlier quoted context omitted.

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…

> Go doesn't offer that for normal errors and there was no clear path to getting it.

It does offer that for normal errors if you pass those errors via exceptions. Although you're right that using exceptions for error handling is pretty weird and generally avoided in Go, much to the chagrin of Java developers.

The Upspin experiment, which eventually shaped the error additions that did make it into Go, showed a clear path to getting it in errors themselves, but it also revealed that nobody actually uses them when available. The research found that even with stack traces attached, developers didn't bother looking at them. Thus why that bit didn't make it into Go.

Re: Golang proposal: container/: generic collection types

#156

Post by typical182 » Sat, Aug 01, 2026, 3:05 PM UTC

win311fwg wrote: post #83

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?

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…

> it finally took convincing Philip Wadler (of Haskell and Java generics fame) to help. Without that lucky break [...] Go probably still wouldn't have generics.

Small correction, I think:

My understanding is the core Go team was already well on its way to doing generics before Philip Wadler became involved, though he and his colleagues were later very helpful.

From Wadler's "Featherweight Go" paper [1] (the first draft of which seems to have been uploaded to arxiv.org circa May 2020):

Recently, the Go team mooted a design to extend Go with generics [Taylor and Griesemer 2019], and Rob Pike wrote Wadler to ask: Would you be interested in helping us get polymorphism right [...]

and:

It took us several tries over many months to formalise it correctly.

Well before that, doing generics was one of the main focuses in the GopherCon keynotes/announcements in 2017 and 2018 by Russ Cox [2].

The August 2018 generics design [3][4] was very detailed, and my recollection is most people in the Go community at that point believed the core Go team was going to make generics happen, even if the team and community were still iterating on the exact design.

Of course, that design improved over time, including thanks to Wadler and crew, but I think it would be overstating things to say that probably nothing would have happened without Wadler.

[1] https://arxiv.org/pdf/2005.11710v1

[2] https://go.dev/blog/go2draft

[3] https://go.googlesource.com/proposal/+/master/design/go2draf...

[4] https://go.googlesource.com/proposal/+/master/design/go2draf...

Re: Golang proposal: container/: generic collection types

#157

Post by win311fwg » Sat, Aug 01, 2026, 3:12 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

There is no case where you would ever trivially send the error up the stack.

First, if your function doesn't have any meaningful information to add, you need to seriously question why the function exists. It is almost certainly not adding anything of value and the function that originally produces the error can just as well be called directly. No need to trivially pass an error when the useless "middleman" function doesn't exist.

Second, even if you still decide that a function that doesn't have worthwhile information is still worthwhile having, if you pass someone else's error straight through then you become forever coupled to the implementation of someone else. If you, for example, pass a SQLite error and then later decide you want to use Postgres, now you have to emulate SQLite errors every time Postgres produces an error, bringing you back to square one while also having one hell of a confusing API. Unless you hate other programmers and are purposely trying to make their life a living hell, the only sensible approach is to produce new error values at each step so that you can maintain stable sentinels/types.

A good language solution for errors might make it look like you are trivially passing an error up the stack while using some other method to attach the necessary metadata, like we see in some other languages, but nobody has yet figured out how to make that fit into Go. It is generally agreed upon that Go would greatly benefit from this, but until someone rolls up their sleeves and solves it...

Re: Golang proposal: container/: generic collection types

#158

Post by Zambyte » Sat, Aug 01, 2026, 3:15 PM UTC

pjmlp wrote: post #106

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…

Actually welcome to Smalltalk, 1980's, because that is where collections, and iteration with blocks, comes from as inspiration to Java, and all the folks that think LINQ was a .NET invention.

And, as with most important lessons in programming, welcome to LISP in the 1950s, because that is where Smalltalk got its inspiration. :-)

Re: Golang proposal: container/: generic collection types

#159

Post by ndriscoll » Sat, Aug 01, 2026, 3:23 PM UTC

kbolino wrote: post #146

ndriscoll wrote: post #145

Earlier quoted context omitted.

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…

That's just pointing out another layer of noise Go introduces. Here again in Scala, you can get stack traces for free with no extra syntax with value-based errors. There are already solutions for doing these things that have been used in anger for many years.

In a language that takes error handling seriously, you have domain types for errors, type checking for exhaustive error handling, and you get info like a stack trace out of the box.

Re: Golang proposal: container/: generic collection types

#160

Post by win311fwg » Sat, Aug 01, 2026, 3:24 PM UTC

pjmlp wrote: post #150

win311fwg wrote: post #120

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. 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.

> Really wearing the team's t-shirt there

Ad hominem is a logical fallacy.

> 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.

Exactly. All these projects chose Go many years before anyone, outside of Docker, had heard of Docker. This idea that Go was some kind of underground language until Docker and Kubernetes arrived at which point everyone jumped on the bandwagon is simply not true. Go was already quite popular by the time Docker was released, as evidenced by a whole lot of other projects that became popular themselves being released at the same time. Those projects wouldn't have been able to have been released when they did if they waited for Docker's success to jump on the Go bandwagon.

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

No there aren't. Not where the language is on the heap of languages nobody has ever heard of. Oberon-2 and Limbo didn't fail because they never found their "Docker", they failed because nobody used them in the first place.