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

Re: Golang proposal: container/: generic collection types

#71

Post by brokencode » Sat, Aug 01, 2026, 12:20 AM UTC

inigyou wrote: post #67

brokencode wrote: post #65

Earlier quoted context omitted.

Nope, I’m saying that the language that was seemingly designed with either an ignorance of or disdain for the hard-won lessons from decades of prior programming languages. There was even this condescending attitude that Google engineers couldn’t understand fancy languages anyway, so they had to dumb Go down. My criticism really isn’t even about Go itself. Yeah it’s improving, which is great. My criticism is about thi…

my criticism is that if we make every language identical, we might as well only have one language. (C++, obviously) There is room for a language without generics. There was a language without generics. Now there is not.

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.

Re: Golang proposal: container/: generic collection types

#72

Post by vlovich123 » Sat, Aug 01, 2026, 12:24 AM UTC

somekyle2 wrote: post #66

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.

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…

The problem is that when you don’t have a cohesive picture of how things fit from the outside, it becomes really hard to evolve the language in a way that makes sense and doesn’t break existing code. Data storage and languages share this unique property that the past impacts your decisions and what makes is possible in the future in a way pure logic doesn’t struggle with.

Re: Golang proposal: container/: generic collection types

#73

Post by jerf » Sat, Aug 01, 2026, 12:27 AM 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.

Do you use Go? Because it sounds like no. In the last four years I've encountered I think two uses of generics in the wild in a 3rd party library. Both quite sensible.

Anyone moaning about how it's ruined Go is either not using Go, or simply impossible to please.

If you hate Go... and hey, you do you, I've got my own list of languages I don't like... find a better complaint because this one is simply nonsensical. "It doesn't let me map/filter/reduce" or "it doesn't fix lock problems" or other similar complaints have some grounding in reality, but this one is just absurd. Generics aren't used enough to be "the worst thing ever". Fears about how Go would instantly turn into a language full of generics that take generic arguments that take generic arguments have proved to be wrong.

Re: Golang proposal: container/: generic collection types

#74

Post by TheDong » Sat, Aug 01, 2026, 12:37 AM UTC

nasretdinov wrote: post #18

athorax wrote: post #6

On one hand I'm glad to see this being added, but its becoming obvious building generics into the language as-is just isn't a good fit. Hopefully Go v2 can solve this at a more foundational level while still allowing interop or easy porting form current go code.

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 make code more readable to okay programmers, it makes code less readable to the average go programmer. To the average go programmer, a union operation is more readable as a for loop which does not have any math-y sounding name at all.

Re: Golang proposal: container/: generic collection types

#75

Post by DarkNova6 » Sat, Aug 01, 2026, 12:37 AM UTC

somekyle2 wrote: post #66

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.

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?

Re: Golang proposal: container/: generic collection types

#76

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

pstuart wrote: post #53

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…

I'm confused by what language regression you are referring to. > Now developers will waste time migrating the code to stdlib Why? If it works now it works. Refactoring tools exist, and LLMs make this trivial. You just seem to hate the language and everything about it, and that's your right but I think your arguments are specious and ignore that most language that go mainstream evolve and that comes with tradeoffs (py…

[deleted]

Re: Golang proposal: container/: generic collection types

#77

Post by interf4ce » Sat, Aug 01, 2026, 1:09 AM UTC

xtracto wrote: post #50

brokencode wrote: post #26

Earlier quoted context omitted.

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.

I'd welcome the ternary conditional operator but I hope exception handling never gets introduced (at least as I'm used to it from Java, C#, JS, etc.).

Exceptions should not be conflated with regular error handling, especially when they're allowed to bubble up from anywhere. I very much appreciate that functions that can return errors force the caller to deal with them, for the most part. True exceptions can already be thrown with panic, although I actually find it incredibly rare that I need to reach for that tool. I'd argue that when people talk about exceptions they almost always actually want "unhappy path" error handling.

Now, if Go wanted to add a sleeker way to handle those errors, similar to Rust's approach, I'd be very interested. Minimum three lines for every call to a function that returns an error does get a bit verbose, arguably hurting readability. A little sugar could improve readability without making error handling implicit.

Re: Golang proposal: container/: generic collection types

#78

Post by TheDong » Sat, Aug 01, 2026, 1:16 AM 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.

> 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 durations, surely the following is more readable?

    parsed, err := slices.MapErr(inputstrings, time.ParseDuration)

I think map functions lead to cleaner code when used like the above, and a lot of for loops end up falling into those patterns.

Re: Golang proposal: container/: generic collection types

#79

Post by Sleaker » Sat, Aug 01, 2026, 1:29 AM UTC

vlovich123 wrote: post #72

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…

The problem is that when you don’t have a cohesive picture of how things fit from the outside, it becomes really hard to evolve the language in a way that makes sense and doesn’t break existing code. Data storage and languages share this unique property that the past impacts your decisions and what makes is possible in the future in a way pure logic doesn’t struggle with.

And this is -exactly- one of the reasons they didn't accept or continue with a sane proposal for more ergonomic error handling. I like go, but this was the one thing that I kept feeling like I was wasting so much time dealing with.

Re: Golang proposal: container/: generic collection types

#80

Post by farfatched » Sat, Aug 01, 2026, 1:55 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?

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's okay too, since Go already has critical mass.