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

21–30 of 207 posts

Re: Golang proposal: container/: generic collection types

#21

Post by pstuart »

cyphar wrote: post #16
pstuart wrote: post #10

Earlier quoted context omitted.

Fair enough. Primeagen did a video recently renouncing his love of Go over the concerns you've raised. That said, I'm assuming much of this "wobbly" functionality will live in libraries and will not be common in day to day coding (much as I've seen with generics so far). It's all optional after all. I use Go because it's simple, capable, and been my prime language for over a decade and that skill enables me to be val…

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 will continue to have enough value to be useful.

Good enough will do for me. I tip my hat to the all the other PL contenders and wish them all well (except Java -- PTSD from that destroyed any love I had for the language).

Re: Golang proposal: container/: generic collection types

#22

Post by aatd86 »

cyphar wrote: post #8
pstuart wrote: post #4

Earlier quoted context omitted.

Sounds like a win to me. I'd assume that many PL decisions come with with costs of either implementation or readability, and Go's conservative evolution takes that into account. Disclaimer: not a PL designer, just a codemonkey. It's not a perfect language, and the process has not been without its pain points, but work like this makes the language more powerful and I feel like I get my money's worth when I use it. Yes…

On the other hand, design decisions made under one set of constraints can become problematic when you add new features that don't play as well with earlier design decisions. 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…

__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 sorts of arguments you can make about simplicity but this is an objective shortcoming of Go that is directly caused by generics being added to Go long post 1.0.__

I'm a bit intrigued by this: how would that work with compatibility between libraries, separate compilation and what not? My first instinct is that it would not be a good idea but I might be missing something..?

Re: Golang proposal: container/: generic collection types

#23

Post by pstuart »

tikhonj wrote: post #12
pstuart wrote: post #4

Earlier quoted context omitted.

Sounds like a win to me. I'd assume that many PL decisions come with with costs of either implementation or readability, and Go's conservative evolution takes that into account. Disclaimer: not a PL designer, just a codemonkey. It's not a perfect language, and the process has not been without its pain points, but work like this makes the language more powerful and I feel like I get my money's worth when I use it. Yes…

"Everything is a trade-off" assumes you're on the Pareto frontier. Go is... very much not on the Pareto frontier of programming language design.

I find language wars tiresome at this point. There was no claim that it was a frontier language, or even that it was a great language. My point was that the Go authors do try to consider the impact of enhancements to the language, which I think is appreciated by many that use it.

Re: Golang proposal: container/: generic collection types

#24

Post by fragmede »

tikhonj wrote: post #12
pstuart wrote: post #4

Earlier quoted context omitted.

Sounds like a win to me. I'd assume that many PL decisions come with with costs of either implementation or readability, and Go's conservative evolution takes that into account. Disclaimer: not a PL designer, just a codemonkey. It's not a perfect language, and the process has not been without its pain points, but work like this makes the language more powerful and I feel like I get my money's worth when I use it. Yes…

"Everything is a trade-off" assumes you're on the Pareto frontier. Go is... very much not on the Pareto frontier of programming language design.

Somewhat. The trade off is it can be made more complex at the cost of its simplicity. You can argue that some of those tradeoffs don't in fact have to be made because it's not on the Pareto frontier, eg generics, but we'd have to have a specific discussion about specific language features instead of vague generic discission about the language.

Re: Golang proposal: container/: generic collection types

#26

Post by brokencode »

PrimalPower wrote: post #9
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.

The beauty of go is YAGNI. Language design makes it much harder for people so do stupid and cute things. During my design process if I start realizing that I’m missing maps, More expressive Types, Or more complex polymorphism. I ask myself if I really need those things. If I really do. I move off of go. That’s the beauty of the language. Go does not need more complicated language features because it’s can handle the…

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 adding them later.

Re: Golang proposal: container/: generic collection types

#27

Post by whateveracct »

tikhonj wrote: post #12
pstuart wrote: post #4

Earlier quoted context omitted.

Sounds like a win to me. I'd assume that many PL decisions come with with costs of either implementation or readability, and Go's conservative evolution takes that into account. Disclaimer: not a PL designer, just a codemonkey. It's not a perfect language, and the process has not been without its pain points, but work like this makes the language more powerful and I feel like I get my money's worth when I use it. Yes…

"Everything is a trade-off" assumes you're on the Pareto frontier. Go is... very much not on the Pareto frontier of programming language design.

> "Everything is a trade-off" assumes you're on the Pareto frontier.

100%. it pisses me off so much that i have to hear this idea thrown around constantly.

Re: Golang proposal: container/: generic collection types

#29

Post by woodruffw »

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.

Is there a categorical division between “library builders” and “ordinary code”? That’s not one I’ve heard before.

(I’m aware of the difference between application and library code, but every large codebase I’ve ever worked in is a mixture of both.)

Post reply on HN