Live data from Hacker News

Golang proposal: container/: generic collection types

github.com

121–130 of 208 posts

Re: Golang proposal: container/: generic collection types

#121

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…

What makes these features unnecessary in 2024 but necessary in 2026?

Re: Golang proposal: container/: generic collection types

#122
post #119

People still calling themselves developers and choosing a language that was created for poor programmers...

The problem good developers have is that they develop software people want to use, and software that people want to use eventually requires more help, and once you need help then it is inevitable that you will need to bring poor programmers into the mix. A good programmer may respect the beauty of Haskell, but it isn't a practical option for them.

Ironically, only poor developers have the luxury of being able to choose something like Haskell as they never have to worry about building something anyone else wants to use.

Re: Golang proposal: container/: generic collection types

#123

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.

Huh? First they said they would: https://youtu.be/rKnDgT73v8s?t=3267 After a decade of nobody coming up with a solution that did turn to believing that Go would never be able to add generics. That is true. The air of defeat did become quite strong. But the Haskell guy did eventually came along to share his expertise and the rest is history.

Re: Golang proposal: container/: generic collection types

#124
post #43

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…

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

Especially within a company more powerful than the individuals. The project was done, at least feature-wise, but then Google set it free to become a community-driven project, which opened the freedom to do new things again: https://go.dev/blog/go2-here-we-come

Re: Golang proposal: container/: generic collection types

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

Re: Golang proposal: container/: generic collection types

#126
post #119

People still calling themselves developers and choosing a language that was created for poor programmers...

It’s the same principle as accessibility. We are all poor programmers sometimes, just as we are all impaired in various ways at times even if we don’t have a disability.

Re: Golang proposal: container/: generic collection types

#127

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?

Go never was "no generics". It had generics rusted in from the get-go, but never implemented them as it was a complex feature and one that made the compiler slower. Im glad they waited. Compare to PHP, where every feature is bolted on and then you end up supporting it forever.

A very common trap I find myself falling into is forgetting that there's a difference between the language, and the most common compiler/interpreter implementation.

It's a very practical simplification since 99% of the time, that's what we use. 'It's in the language, we just don't use it' does sound like copeful technicality, until it isn't and it's an actually impactful difference.

Re: Golang proposal: container/: generic collection types

#128
post #109
post #59

Earlier quoted context omitted.

Go's whole philosophy was to keep the language simple. It's a shame they're abandoning that now and becoming the next C++/Zig/Rust/Java

Turns out programming languages are complex for a reason.

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

Re: Golang proposal: container/: generic collection types

#129
post #59

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.

Go's whole philosophy was to keep the language simple. It's a shame they're abandoning that now and becoming the next C++/Zig/Rust/Java

Those who held that philosophy (Thompson, Pike) are now retired. Those who still have careers ahead of them want to have something to do.

The natural consequence of a "bullshit job" economy.

Re: Golang proposal: container/: generic collection types

#130

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…

Java? No thanks. I have some horrible memories from the ugliness, verbosity of Java. The cherry on the cake is the huge hog of an runtime called the JVM. Also java semi-forces you to have some bulky IDE. Last i looked there was no core java lsp server bundled in the tooling. Java is the enterprise language that make programming suck.

None of that is anything to do with collections
Post reply on HN