Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proposal: Go should have generics

github.com

Post reply on HN
Print view View original

21–30 of 439 posts

Re: Proposal: Go should have generics

#21

Post by drivebyops »

Scarbutt wrote: post #9
f2f wrote: post #2

"The intent is not to add generics to Go at this time, but rather to show people what a complete proposal would look like. We hope this will be of help to anyone proposing similar language changes in the future." This started in 2010. Hopefully an illustration that go's developers are not against generics in general, this ought to quell some of the negativity... Pick one of the four proposals you like :)

They better implement something very near by, Swift is coming for them.

Yea Swift is honestly great to write

Re: Proposal: Go should have generics

#22

Post by slantedview »

slantedview wrote: post #13
bigdubs wrote: post #7

After watching Rob Pike's Go Proverbs talk I am pretty convinced generics, as much as some would want it, will never happen. He proselytizes "just copy a little code here and there" quite clearly, which is at odds with the complexity that generics would add.

It's also at odds with hard-learned lessons of the rest of the software industry, like don't repeat yourself. Golang is doomed to relearn these lessons.

> DRY is a great suggestion but shouldn't be looked at as any type of hard rule

Agree that nothing should be a hard and fast rule. But the significance of DRY is that it increases quality. Not even having the option to "stay DRY" for many problems implemented in Golang will increase bugs. That's just how it is.

Given the tradeoff between the supposed complexity of generics and the very real cost of bugs that will happen from maintaining duplicated code, I'm not sure there's much of a debate to be had.

Re: Proposal: Go should have generics

#23

Post by catfest »

ktamura wrote: post #12
bigdubs wrote: post #7

After watching Rob Pike's Go Proverbs talk I am pretty convinced generics, as much as some would want it, will never happen. He proselytizes "just copy a little code here and there" quite clearly, which is at odds with the complexity that generics would add.

This. For better and for worse, Go was designed for "simplicity", and generics are anything but simple. I'd be very, very surprised if Go thinks about generics in earnest anytime soon. I don't say this in anyway to eulogize Go: In some ways, Go is pathetically unexpressive. That said, it currently fills that gap for writing middleware between C sacrificing too much developer productivity and Perl/Python/Ruby/PHP sacr…

I don't see why you'd choose Go instead of a JVM language like Java, you get the language simplicity (plus features like Generics) and the performance upside too.

Re: Proposal: Go should have generics

#24

Post by ViktorasM »

duaneb wrote: post #18
xiaopingguo wrote: post #3

Why not just fork the language? Why does one language need to do all the things?

Generics are not "all the things". Last i checked there was still no object inheritance (in a subtype sense for interface implementations), no operator overloading, no bytecode/vm/jit, no inline asm, no macros, no pluggable gc, no call/cc, no (idiomatic) exceptions, no currying, no weak typing or implicit conversions, no way of enforcing referential transparency, no STM, no laziness, no assertions, no contracts, no u…

but having all those things go would become another C++ with a different syntax.

I like the direction Go is going of "there are no options to choose", like unconfigurable fmt, or the fact that there is no way to create "exotic" implementations.

However, generics would be my number #1 on the list of "maybe let's add that". Would be nice to have less "interface {}" in reusable libraries.

Exceptions would be probably second, but that would come with some sort of runtime cost. With them Go would start to drift towards "generic programming language".

Re: Proposal: Go should have generics

#26

Post by pcwalton »

ViktorasM wrote: post #24
duaneb wrote: post #18

Earlier quoted context omitted.

Generics are not "all the things". Last i checked there was still no object inheritance (in a subtype sense for interface implementations), no operator overloading, no bytecode/vm/jit, no inline asm, no macros, no pluggable gc, no call/cc, no (idiomatic) exceptions, no currying, no weak typing or implicit conversions, no way of enforcing referential transparency, no STM, no laziness, no assertions, no contracts, no u…

but having all those things go would become another C++ with a different syntax. I like the direction Go is going of "there are no options to choose", like unconfigurable fmt, or the fact that there is no way to create "exotic" implementations. However, generics would be my number #1 on the list of "maybe let's add that". Would be nice to have less "interface {}" in reusable libraries. Exceptions would be probably se…

Exceptions don't have any runtime costs beyond those which Go is already paying by mandating unwinding.

In fact, C++-style exceptions are strictly less expensive in the non-exceptional case than defer, because of defer's dynamic semantics. Go's semantics require a slower exceptional control flow scheme than almost any other language I'm aware of, including dynamic ones like JavaScript.

Re: Proposal: Go should have generics

#27

Post by peteretep »

If they accept generics, then there is an implication that the language design isn't infallible as a result of being written by Rob Pike, and then the whole house of cards falls down as people start clamouring for things like real exceptions.

Re: Proposal: Go should have generics

#28

Post by wrs »

thegenius2000 wrote: post #25

I agree with the author's request, I'm just not convinced he proposes a design. I mean I recognize see the need for some sort of generic programming, but the big question is how not why, right? Edit: My bad. Didn't see the bottom of the page.

He's proposed four designs so far. See the bottom of the page.

Re: Proposal: Go should have generics

#29

Post by riffraff »

catfest wrote: post #23
ktamura wrote: post #12

Earlier quoted context omitted.

This. For better and for worse, Go was designed for "simplicity", and generics are anything but simple. I'd be very, very surprised if Go thinks about generics in earnest anytime soon. I don't say this in anyway to eulogize Go: In some ways, Go is pathetically unexpressive. That said, it currently fills that gap for writing middleware between C sacrificing too much developer productivity and Perl/Python/Ruby/PHP sacr…

I don't see why you'd choose Go instead of a JVM language like Java, you get the language simplicity (plus features like Generics) and the performance upside too.

Single small binaries are easy with go, very hard with java.

Re: Proposal: Go should have generics

#30

Post by lomnakkus »

BinaryIdiot wrote: post #20
slantedview wrote: post #13

Earlier quoted context omitted.

It's also at odds with hard-learned lessons of the rest of the software industry, like don't repeat yourself. Golang is doomed to relearn these lessons.

> It's also at odds with hard-learned lessons of the rest of the software industry, like don't repeat yourself. There is nothing wrong with repeating things. It's important to NOT repeat many things but everything? No way. DRY is a great suggestion but shouldn't be looked at as any type of hard rule. For instance I've been on projects where DRY was taken to such an extreme that even the function decorators (plus thei…

I'm not seeing where the parent poster suggested taking DRY to such extremes.

The fact that a feature can be abused doesn't mean that it's a worthless feature. If that were the case there'd be no progress in programming languages because basically every feature can be abused. What matters is the balance between how easy it is to abuse (accidentally or not) vs. how useful it is when not abused (such as added expressivity/safety/DRYness/etc.).

Post reply on HN