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

191–200 of 207 posts

Re: Golang proposal: container/: generic collection types

#191

Post by vips7L »

tzone wrote: post #175
Pooge wrote: post #147

Earlier quoted context omitted.

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

Those options will exist soon:

https://news.ycombinator.com/item?id=49119063

Re: Golang proposal: container/: generic collection types

#192

Post by dwattttt »

bheadmaster wrote: post #183
everybodyknows wrote: post #172

> 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]"?

What do you mean by "strict typing of its index"?

I expect it's referring to the newtype pattern; you don't want to accidentally add inches to cm, so if you have to handle both of them a lot, you make a single field struct Inches and one for Cm.

For containers, you can do this to make it a type error to index the container with anything other than the newtype you made.

In some languages you can replace/implement the indexing operation a[i] with your new type, so the code looks the same as usual, but gets the benefit of preventing the wrong 'integer' from being used.

Re: Golang proposal: container/: generic collection types

#193

Post by znpy »

pjmlp wrote: post #112
znpy wrote: post #64

Earlier quoted context omitted.

Absolutely, i was just being ironic :)

What do you think Kubernetes is? Go EE is the plethora of CNCF projects.

> What do you think Kubernetes is?

Essentially an abstraction layer above the infrastructure (physical or virtual).

Considering it was released by google AFTER the launch of google cloud platform, i honestly see it as a way to make apps more easily portable off AWS.

Re: Golang proposal: container/: generic collection types

#194

Post by pjmlp »

znpy wrote: post #193
pjmlp wrote: post #112

Earlier quoted context omitted.

What do you think Kubernetes is? Go EE is the plethora of CNCF projects.

> What do you think Kubernetes is? Essentially an abstraction layer above the infrastructure (physical or virtual). Considering it was released by google AFTER the launch of google cloud platform, i honestly see it as a way to make apps more easily portable off AWS.

Google Cloud platform is based on the internal proprietary version of Kubernetes, Borg.

Re: Golang proposal: container/: generic collection types

#196

Post by kamma4434 »

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…

I personally do not care about GC - in the last 15 years it’s been a solved issue. Where imho the JVM rocks, is that you can instrument it in production

Re: Golang proposal: container/: generic collection types

#197

Post by pstuart »

pjmlp wrote: post #185
pstuart wrote: post #171

Earlier quoted context omitted.

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.

Fast compilers with generics wasn't rocket science. Of course the language is for dumb people, Rob Pike even said it officially, poor souls that apparently cannot master better tools, even though they are able to work around Google's stupid hiring practices.

It would be a mistake to confuse simple for dumb.

His comment about making it easy for junior engineers was about pragmatic software engineering and being able to deliver product at scale.

There's plenty of far more advanced programming languages, e.g., Lisp, OCaml, Haskell, and even C++ as far as power of the language. But only one of those has gone mainstream and it was the C++ compilation time that inspired Go and Rust was also trying to be a better way to code within that paradigm.

It's a matter of taste, and while hating being forced to use a language you don't like to use is one thing, hating the language itself is silly -- it's like hating roses because you like orchids.

And if you think the original Go team was composed of dumb people you are also mistaken. They built a language they wanted to use, which I'd posit is a signal of "worthiness". Many people (including myself) enjoy using the language and it's created a lot of value in the software ecosystem.

Re: Golang proposal: container/: generic collection types

#198

Post by bheadmaster »

vips7L wrote: post #190
bheadmaster wrote: post #184

Earlier quoted context omitted.

Yeah, they have to be in order to make up for the braindead decision of making every variable a pointer to heap allocated memory. Go wins not by technical ingenuity, but by simply not making fundamentally bad decisions in the first place.

This will also be an outdated take in a few months. What’s next?

I assume you're referring to value classes?

The very fact that Project Valhalla had to create new opt-in syntax for value classes, in order to get what Go does by default on all its types, is the admission of defeat of a herculean battle of attempting to optimize desite fundamental problems with Java's design.

Value classes won't make criticism outdated, because they don't fix any fundamental problems, they just provide an opt-in feature with significant restrictions.

Re: Golang proposal: container/: generic collection types

#199

Post by kubanczyk »

hwc wrote: post #137
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…

> Developers can't pick it up in a week... I don't think any of the new additions to the library have seriously made the learning curve more difficult. I suspect that most projects don't use templates at all. There have always been parts of the standard library I'm not familiar with. when I read code that uses it, I just go read the documentation. Now the standard library is just larger.

> I don't think any of the new additions to the library have seriously made the learning curve more difficult.

Ah, so you haven't looked into json/v2 yet.

Re: Golang proposal: container/: generic collection types

#200

Post by kubanczyk »

everybodyknows wrote: post #172

> 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]"?

> Is there a way now to define a slice-based type that enforces strict typing of its index

Nope, no way to do that.

I wonder about ergonomics. I can imagine "academic" usage, but I shudder at the perspective of the impact on a typical CRUD app.

Post reply on HN