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

91–100 of 207 posts

Re: Golang proposal: container/: generic collection types

#91

Post by farfatched »

ako wrote: post #86
farfatched wrote: post #80

Earlier quoted context omitted.

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…

Go value proposition for me, when developing with Claude code: 1) fast compilation times, faster iterations, 2) user friendly to install, one single binary per platform, 3) feels safer than JavaScript/typescript, which have too many npm vulnerabilities. Go comes with more functionality included, less need to use 3rd party libraries.

That's fair. In addition, I'd add the great compatibility guarantees, and a community that makes easy-to-learn libraries.

Re: Golang proposal: container/: generic collection types

#92

Post by lilbigdoot »

danieldc wrote: post #61
typical182 wrote: post #56

Earlier quoted context omitted.

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.

Yes, .NET had the benefit of coming second and using F#, which was originally essentially OCaml 4 on .NET, as it's testing grounds. Same for Async

I am considering .NET for one of my compilers backends because of the reified generics. .NET can even pass around an object with generic methods that get specialized via JIT at runtime each time it sees a new data type (with reference types sharing implementations). Which also ties back to having true value types

It's a shame it took so long for .NET core to come around because even today the platform carries a reputation for being windows first which hasn't really been true for many years now

Re: Golang proposal: container/: generic collection types

#93

Post by tyre »

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.

Python uses comprehensions because whitespace sensitivity was a horrendous language decision, then couldn’t find a way to support multiline lambdas.

Comprehensions are not a well-designed feature but a consequence of poor design.

Re: Golang proposal: container/: generic collection types

#94

Post by LVB »

farfatched wrote: post #80
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?

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…

I don’t feel like the learning curve has shifted dramatically for mainstream development. Besides generics—which tend to not show up that often in app code even now—I can’t think of any substantial language change since I Iearned it in 2014. (Well, modules, but that’s more tooling.) Where I do see the shock is jumping to def of a std lib function and landing in indecipherable type soup.

Re: Golang proposal: container/: generic collection types

#95

Post by metaltyphoon »

danieldc wrote: post #61
typical182 wrote: post #56

Earlier quoted context omitted.

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.

C# was meant to have generics in day one, but it didn’t make the cut and it was introduced on the next version (2.0)

Re: Golang proposal: container/: generic collection types

#96

Post by metaltyphoon »

brokencode wrote: post #71
inigyou wrote: post #67

Earlier quoted context omitted.

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.

I think when people mention generics, they don’t mean builtins from the language but a language construct for generics.

Re: Golang proposal: container/: generic collection types

#98

Post by kamma4434 »

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 you can turn any collection into a synchtonized or readonly doppelganger with one line of code. Collections are nice and I miss them in Golang)

Re: Golang proposal: container/: generic collection types

#100

Post by troupo »

inigyou wrote: post #59
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.

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

They threw many babies out with the bathwater chasing yhe rather unspecified "simplicity" and making parts of the lsngusge more complex to use as a result.
Post reply on HN