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

171–180 of 207 posts

Re: Golang proposal: container/: generic collection types

#171

Post by pstuart »

pjmlp wrote: post #111
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…

You mean how Ada, Delphi, D, OCaml compile?

And your point is?

They didn't know how to do it "correctly" -- it took outside help from Philip Wadler (who helped with Generics in Java) to make it work acceptably.

Of course the core team were a big bunch of dumb old stupidheads and they made a dumb language for dumb people, so you win, you're smarter than them.

Re: Golang proposal: container/: generic collection types

#172

Post by everybodyknows »

> Since the addition of generics in Go 1.18 and iterators in Go 1.23, it has become possible for library-defined types to achieve comparable ergonomics to built-in types ...

For those who've been following Golang more diligently than myself: Is there a way now to define a slice-based type that enforces strict typing of its index, and yet preserves the compactness of the standard syntax "s[i]"?

Re: Golang proposal: container/: generic collection types

#173

Post by pstuart »

wbl wrote: post #68
pstuart wrote: post #21

Earlier quoted context omitted.

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.

I see a lot of overlap between Go and Rust -- with Go's "advantages" being simpler code to reason about and more ergonomic concurrency.

As Rust and its ecosystem mature and LLMs get better and cheaper, I imagine we'll see more ports of Go projects to Rust.

I love Go and admire Rust but I didn't have the energy to get through the learning curve, and Go does enough for me for what I need so I'll be ok if I never properly use or master Rust.

An ex-boss loathed Go and cited "but the nil pointers!" as his reasoning for his contempt and made sure to migrate the flagship project written in Go to Rust. People get emotional over languages but they're just tools and not worth fighting over.

Re: Golang proposal: container/: generic collection types

#174

Post by age123456gpg »

Pooge wrote: post #147
tzone wrote: post #134

Earlier quoted context omitted.

People use Go vs Java not because of the language differences but because of massive improvement that GO runtime is compared to JVM. It is crazy that people still don't understand why JVM sucks, and why GO's approach to minimize GC pause latency is far superior design decision compared to whatever JVM has been trying to do with its GC iterations for god knows how many years with gazzillion different variants that all…

I'm the biggest fanboy of Go, but since Java 25 the default garbage collector (ZGC) is very similar to Go's.

Very similar, in the same way non-compacting and non-generational collector is similar to compacting generational :shrug:

Re: Golang proposal: container/: generic collection types

#175

Post by tzone »

Pooge wrote: post #147
tzone wrote: post #134

Earlier quoted context omitted.

People use Go vs Java not because of the language differences but because of massive improvement that GO runtime is compared to JVM. It is crazy that people still don't understand why JVM sucks, and why GO's approach to minimize GC pause latency is far superior design decision compared to whatever JVM has been trying to do with its GC iterations for god knows how many years with gazzillion different variants that all…

I'm the biggest fanboy of Go, but since Java 25 the default garbage collector (ZGC) is very similar to Go's.

Garbage collector alone can't do what happens in Go language+runtime. Simplest example is that there is no way to allocate fixed arrays with non-pointer structs in Java. That is just not possible in the language.

Design of Go allows programmer to rewrite their program to make it as GC efficient as needed. You can even have essentially zero GC overhead and do stuff manually for really high performance needs. And you can also write regular code when GC isn't a big deal.

Those options simply don't exist in Java language. Your only bet in Java would be to embed some C code which is a nightmare of its own.

There is a reason why almost all backened systems that run on JVM are a huge pain in the ass even at moderate scale. They all end up rewriting parts in other languages and at the end just rewriting the whole thing.

Re: Golang proposal: container/: generic collection types

#176

Post by blandflakes »

pjmlp wrote: post #108
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…

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.

And the kubernetes code and APIs still read like corporate Java for years after, too

Re: Golang proposal: container/: generic collection types

#177

Post by aatd86 »

cyphar wrote: post #85
aatd86 wrote: post #22

Earlier quoted context omitted.

__For a concrete example, the fact you cannot define custom methods for external types in Go (a pre-1.0 design decision) means that you cannot write proper compile-time generic code to deal with some generic wrapping type (dumb example -- getting a sum of the perimeters of a generic set of shapes in an externally-defined collection type) -- you are forced to work around it with runtime type-switching. There are all s…

In Rust this is solved by defining a local trait and methods implemented for a trait are only available if the trait is imported. This is in contrast to Go where methods are not namespaced at all. But there are almost certainly many other ways of solving the problem. I was a little surprised how often I ran into this issue when using libraries that started defining structures as generic containers.

Yes, so that is exactly what I don't understand, that makes compilation flow sensitive in a way that Go avoids by design in order to remain fast.

Re: Golang proposal: container/: generic collection types

#178

Post by vips7L »

tzone wrote: post #134
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…

People use Go vs Java not because of the language differences but because of massive improvement that GO runtime is compared to JVM. It is crazy that people still don't understand why JVM sucks, and why GO's approach to minimize GC pause latency is far superior design decision compared to whatever JVM has been trying to do with its GC iterations for god knows how many years with gazzillion different variants that all…

Pretty outdated take. Java’s GCs are a generation ahead of Go’s.

Re: Golang proposal: container/: generic collection types

#179

Post by vips7L »

shikck200 wrote: post #115
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…

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.

Go is far more verbose and uglier than Java ever will be.

Re: Golang proposal: container/: generic collection types

#180

Post by sideeffffect »

shikck200 wrote: post #115
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…

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.

The official VS Code extension from Oracle with an LSP server:

https://marketplace.visualstudio.com/items?itemName=Oracle.o...

Post reply on HN