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

31–40 of 439 posts

Re: Proposal: Go should have generics

#31

Post by bigdubs »

slantedview wrote: post #14
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…

Generics can be (relatively) simple - see C#, they just tend not to be in many implementations.

CLR (the C# runtime) generics are fully reified and about the most complicated and robust implementation available. It dynamically emits and loads types whenever a new generic parameter is seen for a function or type. This is very, very hard to get right and is not very performant. It also puts a lot of burden on the runtime vs. the compiler. Go expressly tries to keep the runtime as small as possible.

Re: Proposal: Go should have generics

#32

Post by incepted »

riffraff wrote: post #29
catfest wrote: post #23

Earlier quoted context omitted.

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.

> Single small binaries are easy with go

With static linking? I don't think so.

Re: Proposal: Go should have generics

#33

Post by duaneb »

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…

This was basically the point I was trying to make. :)

Re: Proposal: Go should have generics

#34

Post by enneff »

peteretep wrote: post #27

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.

Your comment does a great disservice to Robert Griesemer, Ken Thompson, and the many others who contributed to Go's design.

Re: Proposal: Go should have generics

#36

Post by duaneb »

pcwalton wrote: post #26
ViktorasM wrote: post #24

Earlier quoted context omitted.

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.

IIRC the idea is that the conceptual overhead of exceptions is much larger than the runtime cost, hence the minimal syntax/runtime support beyond defer (which is easy to follow, if hard to implement efficiently).

I am not so sure I would agree with this, but I don't use go enough to have a firm opinion myself.

Re: Proposal: Go should have generics

#37

Post by ktRolster »

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…

I wouldn't mind seeing a powerful contracts implementation in C++. (Or any language, really).

Re: Proposal: Go should have generics

#38

Post by pcwalton »

duaneb wrote: post #36
pcwalton wrote: post #26

Earlier quoted context omitted.

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.

IIRC the idea is that the conceptual overhead of exceptions is much larger than the runtime cost, hence the minimal syntax/runtime support beyond defer (which is easy to follow, if hard to implement efficiently). I am not so sure I would agree with this, but I don't use go enough to have a firm opinion myself.

Try/catch/finally is simpler than panic/recover/defer both conceptually and in implementation, due to the statically, lexically-scoped semantics.

Re: Proposal: Go should have generics

#39

Post by danellis »

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.

That comes with a big memory cost, though. Also huge startup time, so not suitable for command line tools.

Re: Proposal: Go should have generics

#40

Post by enneff »

pcwalton wrote: post #38
duaneb wrote: post #36

Earlier quoted context omitted.

IIRC the idea is that the conceptual overhead of exceptions is much larger than the runtime cost, hence the minimal syntax/runtime support beyond defer (which is easy to follow, if hard to implement efficiently). I am not so sure I would agree with this, but I don't use go enough to have a firm opinion myself.

Try/catch/finally is simpler than panic/recover/defer both conceptually and in implementation, due to the statically, lexically-scoped semantics.

As you probably already know, panic/recover/defer are not supposed to be used in the same way as try/catch/finally. They're different features for different purposes.

If you want error handling in Go, use error values.

Post reply on HN