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

101–110 of 207 posts

Re: Golang proposal: container/: generic collection types

#101

Post by kamma4434 »

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…

> Go without generics was ok. I say that as a fan of generics in other languages.

Well kinda. I found it very annoying every time you want to print a sorted map which keys are strings that you could not abstract the operation. It felt like paying a stupidity tax. (And I quite like go. It’s the only language where write once run everywhere actually works. Cross compiling for all targets is as easy as creating a local binary)

Re: Golang proposal: container/: generic collection types

#102

Post by Quitschquat »

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.

This used to be the popular take not long ago. Now it's grayed out and unpopular.

Re: Golang proposal: container/: generic collection types

#103

Post by overfeed »

rattlesnakedave wrote: post #82
TheDong wrote: post #74

Earlier quoted context omitted.

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

some of us that have to work with people like you are happy that you're constrained by Go.

My wish (curse?) on everyone who puts language "expressiveness" on a pedestal, is that their very clever colleagues express themselves creatively, in every codebase they set eyes on from now till eternity.

Re: Golang proposal: container/: generic collection types

#104

Post by gritzko »

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.

Java started as a language to write apps on the Internet (applets). Then, it evolved into an elephantine corporate-focused language, because that's where the money is. I remember those Java applets that took minutes to load. The Web was taken over by JavaScript instead, which was famously coded in ten days.

Go used very particular shortcuts to make its GC'd runtime lightweight enough and the language simple enough. But, due to Conway's law or something else, it was destined to become a corporate-focused elephantine language, gradually.

I remember 10 years ago I believed that Go lacked something like STL. Later I changed my opinion cause I started to realize how much overhead red-black trees and suchlikes introduce. Especially in GC'd systems. This abstraction Jenga may indeed look shockingly absurd when you see all the moves in the system, not just your layer.

In performance-critical cases, I personally use ABC, a C dialect with solid containers. Those are basically chunks of RAM with fixed-bit-layout records in them. Vectors, hash maps and hash sets, heaps and queues are all just arrays. If we only needed that, we might have stayed with C. Solid containers require no malloc() and no GC. Can mmap them and you have a database. Can send them over the network as-is. That is the ultimate 80/20 thing here. LMDB is another example.

But if you keep adding features, 80/20 is no more and your Go becomes an uglier Java or Rust.

Re: Golang proposal: container/: generic collection types

#105

Post by pjmlp »

win311fwg wrote: post #83
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?

Does it? It was only preventable by not releasing Go, which isn't exactly the greatest of solutions. As you know from when Go was first broadcast to the world, they hadn't figured out how to make generics fit[1]. It is not like they weren't trying. Ian Lance Taylor is regarded for beginning work on generics before anyone outside of Google had even heard of Go. "In short: not yet" What was surprising is that after Go…

More like no one on the world was able to change their mind, and then they had to ask help to someone that could already have provided help before Go released 1.0 version.

"They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."

https://go.googlesource.com/proposal/+/master/design/go2draf...

Re: Golang proposal: container/: generic collection types

#106

Post by pjmlp »

kamma4434 wrote: post #98

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…

Actually welcome to Smalltalk, 1980's, because that is where collections, and iteration with blocks, comes from as inspiration to Java, and all the folks that think LINQ was a .NET invention.

Re: Golang proposal: container/: generic collection types

#107

Post by pjmlp »

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…

People always forget this other post when arguing for the home team.

"They are likely the two most difficult parts of any design for parametric polymorphism. In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier."

https://go.googlesource.com/proposal/+/master/design/go2draf...

Re: Golang proposal: container/: generic collection types

#108

Post by pjmlp »

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…

Go only took off thanks to Docker pivot from Python into Go, and Kubernetes from Java into Go, after the respective teams got some Go folks into the project.

The usual RIX approach, followed the whole devops hype cycle that created all those CNCF projects half of which no one in devops space actually knows they exist.

Re: Golang proposal: container/: generic collection types

#109

Post by pjmlp »

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

Turns out programming languages are complex for a reason.

Re: Golang proposal: container/: generic collection types

#110

Post by pjmlp »

tyre wrote: post #93
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.

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.

Nope, as someone there at the time, they are an influence how language like Haskell do them.

Which by the way has no issues being whitespace sensitive and having multiline lambdas.

The only reason Python doesn't support them is Guido not wanting to have them.

Post reply on HN