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

61–70 of 207 posts

Re: Golang proposal: container/: generic collection types

#61

Post by danieldc »

typical182 wrote: post #56
tialaramex wrote: post #49

Earlier quoted context omitted.

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

FWIW, C# generics are way better (ergonomics) than the Java ones (due to type erasure), so Java waited too much. History is more complicated though for Java, since it was either having some generics vs having none. See [this](https://softwareengineering.stackexchange.com/questions/1766...) for a lengthier discussion.

Re: Golang proposal: container/: generic collection types

#63

Post by theowaway213456 »

inigyou wrote: post #58
astonex wrote: post #48

Earlier quoted context omitted.

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?

errgroup has a SetLimit function to control the max number of concurrent go routines running at once.

Re: Golang proposal: container/: generic collection types

#64

Post by znpy »

throw_m239339 wrote: post #44
znpy wrote: post #19

Looking forward to see G2EE being released as a specification /s

Nothing wrong with J2EE back then if you were building a certain kind of entreprise application. EJBeans actually took care about a lot of business complexity for a n-tier application, it's just that the whole XML crap was absolutely egregious. Go can barely parse an XML document natively so don't worry about G2EE I'd say... I'm more worried about what have become of professional Javascript serverside these days, it'…

Absolutely, i was just being ironic :)

Re: Golang proposal: container/: generic collection types

#65

Post by brokencode »

cyberpunk wrote: post #51
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…

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 the…

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 this anti-intellectual attitude that has permeated the entire Go community since its inception. It’s like hearing that college is a waste of time from people who never graduated high school.

Re: Golang proposal: container/: generic collection types

#66

Post by somekyle2 »

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 more successful examples to borrow from, so waiting for enough practical experience to make the relevant trade-offs on practical grounds isn't the bare naivety that some people seem to take it as.

Re: Golang proposal: container/: generic collection types

#67

Post by inigyou »

brokencode wrote: post #65
cyberpunk wrote: post #51

Earlier quoted context omitted.

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 the…

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.

Re: Golang proposal: container/: generic collection types

#68

Post by wbl »

pstuart wrote: post #21
cyphar wrote: post #16

Earlier quoted context omitted.

I've maintained one of the major container runtimes (which is written in Go) for over a decade as well, I think I have a less rosy view of Go than you but I still think it's a nice language all things considered and still use it for some projects.

My goal is to be pragmatic about the issue (and everything else). When I started with it I saw it as the love-child of C and python. Then saw it as a successor of Java. I recognize that Rust will win this contest (although my understanding is that async still has sharp edges to round down). I'm old and tired and have lost the energy and focus for exploring new languages and believe that despite its shortcomings it wi…

Rust will not "win" when it targets a much different niche, any more than C won against Java or Scheme.

Re: Golang proposal: container/: generic collection types

#69

Post by wbl »

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…

Nothing was broken in the change: there is no need to migrate.
Post reply on HN