Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Golang proposal: container/: generic collection types

github.com

Post reply on HN
Print view View original

51–60 of 207 posts

Re: Golang proposal: container/: generic collection types

#51

Post by cyberpunk »

brokencode wrote: post #26
PrimalPower wrote: post #9

Earlier quoted context omitted.

The beauty of go is YAGNI. Language design makes it much harder for people so do stupid and cute things. During my design process if I start realizing that I’m missing maps, More expressive Types, Or more complex polymorphism. I ask myself if I really need those things. If I really do. I move off of go. That’s the beauty of the language. Go does not need more complicated language features because it’s can handle the…

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…

So your argument is that they should have gotten it exactly right first time and stuck to their guns?

I mean come on. The Golang team created a useful language people use for building real things — it’s easy to work with especially on large teams, and when the lack of generics turned out to be a pain point in the end (after years of production reality) they understood what the community wanted and actually… added them..

Now what, it’s not good enough?

No one forced you to use go.

No programming language is perfect. I personally find the language has served me well.

And after being so very pro generics myself, i actually find myself not even really using them that much apart from calling the slices module etc which has them under the hood anyway…

Re: Golang proposal: container/: generic collection types

#52

Post by ninkendo »

improgrammer007 wrote: post #33
amazingamazing wrote: post #32

Earlier quoted context omitted.

What’s wrong with meeting demand?

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 generics was another year of workarounds and tech debt building up that would have otherwise been able to be written the right way from the start. Unlike ewaste though, it’s probably impossible to quantify.

[0] I’d probably peg N as the years between when they gave MacBooks USB-C ports for charging, up until the iPhone got them. It’s clear Apple knew they were gonna need to move to it eventually… every year in that period represents a year of lightning cables people bought that could have been still-useful USB-C cables today.

Re: Golang proposal: container/: generic collection types

#53

Post by pstuart »

improgrammer007 wrote: post #45
pstuart wrote: post #43

Earlier quoted context omitted.

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…

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 (python2 -> python3, rust in general, etc).

And as far as deliverables go, the code is absolutely foundational to that and Go was made to be maintainable by codemonkeys such as myself.

Anyway, the language and the changes noted in the OP apparently aren't for you and that's ok -- there's plenty of languages out there for everyone's taste.

Re: Golang proposal: container/: generic collection types

#54

Post by tialaramex »

ninkendo wrote: post #39
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.

IMO it depends on the language… to me, map/collect/etc are useful in languages that have the concept of immutable data, because you can initialize an array with a single call chain, and be sure that nothing after that can modify it. What I’ve seen in the “for loop” approach that I can’t stand, are things like (pseudo code) var a = [] for x in coll1 { a.push(foo(x)) } do_stuff_with(a) // … further down the function fo…

Often the mutation might have performance benefits.

Of course if you're Rust the stdlib and compiler might conspire to optimise an operation you wrote which reads as non-mutating into an actual mutation which was faster.

This is another benefit of the "destructive move". If I consume X and spit out Y, the X is gone, so it's OK if secretly I just mutate X and tell you that's Y now.

Re: Golang proposal: container/: generic collection types

#55

Post by bborud »

silverwind wrote: post #5
troupo wrote: post #2

Go is rediscovering Guy Steele's Growing a Language from first principles, at a much slower pace: https://youtu.be/_ahvzDzKdB0?is=qZdfiT3792XyHxSJ

It's sad that such basic stuff took this long. If we're lucky we might even see a `Map` function in our lifetimes.

This is also why people eventually leave languages. Satisfy everyone’s wishes for long enough and you get lots of different styles of doing things and … «wow look at that much simpler language over there; let’s try that instead»

Re: Golang proposal: container/: generic collection types

#56

Post by typical182 »

tialaramex wrote: post #49
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…

I guess it's possible that C# and Java taught the wrong lesson (you can add this later) and that actually reduced the impetus to ensure Go shipped generics in 1.0 It is also entirely fair to say there's a lot of complexity here and so there's a risk you exceed your complexity budget which for Go as I understand it was very slim. It is a possible a Go 1.0 with more generics doesn't take off because too many people bou…

From what I've seen, I don't think the core Go team was ignoring the lessons of Java or C#.

Here's a sample quote from Russ Cox from 11 years ago on this site: [1]

We have spoken to a few true experts in Java generics and each of them has said roughly the same thing: be very careful, it's not as easy as it looks, and you're stuck with all the mistakes you make. As a demonstration, skim through most of http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.ht... and see how long before you start to think "was this really the best way to do this?"

And of course, they asked other experts for help, including Philip Wadler (of Featherweight Java and Haskell fame): [2] [3]

We’ve been thinking about generics since work on Go began, and we wrote and rejected our first concrete design in 2010. We wrote and rejected three more designs by the end of 2013. Four abandoned experiments, but not failed experiments, We learned from them, [...]

Last year [2018] we started exploring and experimenting again, and we presented a new design [...] and we’ve been working with programming language theory experts to understand the design better.

[1] https://news.ycombinator.com/item?id=9622417

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

[3] https://go.dev/blog/generics-next-step#acknowledgements

Re: Golang proposal: container/: generic collection types

#57

Post by jppittma »

improgrammer007 wrote: post #45
pstuart wrote: post #43

Earlier quoted context omitted.

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…

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.

Re: Golang proposal: container/: generic collection types

#58

Post by inigyou »

astonex wrote: post #48
nasretdinov wrote: post #17

Earlier quoted context omitted.

Also having stuff like a concurrency limiter (instead of doing weird var limiter chan struct{} and using it as `limiter <- struct{}{}` and `defer <-limiter`) as a library function in `sync` package would be great too.

There is actually a way to do this with errgroup provided you can work with func() error signature https://pkg.go.dev/golang.org/x/sync/errgroup#Group.SetLimit

Error 403. Summarize?

Re: Golang proposal: container/: generic collection types

#59

Post by inigyou »

silverwind wrote: post #5
troupo wrote: post #2

Go is rediscovering Guy Steele's Growing a Language from first principles, at a much slower pace: https://youtu.be/_ahvzDzKdB0?is=qZdfiT3792XyHxSJ

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

Re: Golang proposal: container/: generic collection types

#60

Post by amazingamazing »

improgrammer007 wrote: post #33
amazingamazing wrote: post #32

Earlier quoted context omitted.

What’s wrong with meeting demand?

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

It is not a monolith, maintainers change? Why does it matter so much to you anyway? You can choose not to use generics
Post reply on HN