5 ms·

I look forward to the time when Go adds generics and all the people who told me that you don't need generics in Go start telling me how awesome and super-duper

I look forward to the time when Go adds generics and all the people who told me that you don't need generics in Go start telling me how awesome and super-duper useful generics are.

dvirsky 12y ago
I haven't heard anyone, including the go authors, say that generics are bad and you absolutely don't need them in Go. Personally I like Go a lot and don't miss generics much, but for some things I'd love to use generics some day. It's basically about trade-offs eventually. To quote the FAQ about it: > enerics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do. > Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.
dilap 12y ago
Here's rsc (one of the core Go dev's page) on generics. http://research.swtch.com/generic http://research.swtch.com/generic They do believe it's a useful feature, they just don't think the tradeoffs justify it yet. (People who loudly clamor for generics tend to ignore these tradeoffs.)
- frowaway001 12y ago
  I'd love if people would stop linking to something which is so obviously wrong (or at least read it before linking). Go devs made it clear that Go won't get Generics, and it's fine.
- marvy 12y ago
  Unfortunately, that thing is a false trichotomy. The fact is, choosing option 1 does not save you from the consequences of options 2 and 3. The reason is that the programmer now has to make a choice between boxing things manually, or implementing the same algorithm multiple times, just as the compiler would have done. So in reality there is a dichotomy: slow compiles, or slow runtimes.
  - dilap 12y ago
    Definitely some truth to this, but in practice, the fact that you have to manually do things means that you'll make decent choices -- you'll use interfaces for most stuff, and specialize the stuff that needs to be concrete, and life will be OK, if a bit clumsy. With generics, it's easy to end up in a situation where just by instantiating some simple-seeming class, you get a whole giant pile of stuff, more than any sane programmer would create by hand. (I wish I had it at hand, but there was an excellent post from a .NET/CLR guy a while back that went into all the crazy stuff that got instantiated just by creating one specialization of List<T>, the associated performance overheads, and the things the compiler and runtime tried to do to avoid those.)
    - marvy 12y ago
      That bad? Wow. I would love to read that.
    - sigmaml 12y ago
      You should, however, note that Go does not have inheritance. That single difference reduces the `crazy stuff' by an order of magnitude. In addition, not having inheritance also means that you do not need to take variance into account, which further reduces the complexity significantly.
sangnoir 12y ago
As far as I recall, the apologists don't say generics are bad - but rather, not necessary (at times conceding they are useful). Which sounds reasonable to me. Who needs generics? 'Need' in it's dictionary sense. i.e. is there an algorithm you can't write in a language because the language lacks generics? Great to have? Yes. Need? No.
- frowaway001 12y ago
  Yet another Turing tarpit argument?
ansible 12y ago
I predict that there will be some kind of support for generics... eventually. Not explicitly in the language itself, but some added 'go generate' style tooling support. You will be able to define containers and such to use the empty interface, and add in some comments saying you want a version for strings, or floats. And the generate step will run to create the type-specific versions, which will then be compiled as usual. There's definitely work to be done in the details. This is my general read on where I think the community and developers are going... that's all.

I look forward to the time when Go adds generics and all the people who told me that you don't need generics in Go start telling me how awesome and super-duper useful generics are.

dvirsky 12y ago

I haven't heard anyone, including the go authors, say that generics are bad and you absolutely don't need them in Go. Personally I like Go a lot and don't miss generics much, but for some things I'd love to use generics some day. It's basically about trade-offs eventually. To quote the FAQ about it: > enerics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do. > Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.

dilap 12y ago

Here's rsc (one of the core Go dev's page) on generics. http://research.swtch.com/generic http://research.swtch.com/generic They do believe it's a useful feature, they just don't think the tradeoffs justify it yet. (People who loudly clamor for generics tend to ignore these tradeoffs.)

frowaway001 12y ago
I'd love if people would stop linking to something which is so obviously wrong (or at least read it before linking). Go devs made it clear that Go won't get Generics, and it's fine.
marvy 12y ago
Unfortunately, that thing is a false trichotomy. The fact is, choosing option 1 does not save you from the consequences of options 2 and 3. The reason is that the programmer now has to make a choice between boxing things manually, or implementing the same algorithm multiple times, just as the compiler would have done. So in reality there is a dichotomy: slow compiles, or slow runtimes.
- dilap 12y ago
  Definitely some truth to this, but in practice, the fact that you have to manually do things means that you'll make decent choices -- you'll use interfaces for most stuff, and specialize the stuff that needs to be concrete, and life will be OK, if a bit clumsy. With generics, it's easy to end up in a situation where just by instantiating some simple-seeming class, you get a whole giant pile of stuff, more than any sane programmer would create by hand. (I wish I had it at hand, but there was an excellent post from a .NET/CLR guy a while back that went into all the crazy stuff that got instantiated just by creating one specialization of List<T>, the associated performance overheads, and the things the compiler and runtime tried to do to avoid those.)
  - marvy 12y ago
    That bad? Wow. I would love to read that.
  - sigmaml 12y ago
    You should, however, note that Go does not have inheritance. That single difference reduces the `crazy stuff' by an order of magnitude. In addition, not having inheritance also means that you do not need to take variance into account, which further reduces the complexity significantly.

sangnoir 12y ago

As far as I recall, the apologists don't say generics are bad - but rather, not necessary (at times conceding they are useful). Which sounds reasonable to me. Who needs generics? 'Need' in it's dictionary sense. i.e. is there an algorithm you can't write in a language because the language lacks generics? Great to have? Yes. Need? No.

frowaway001 12y ago
Yet another Turing tarpit argument?

ansible 12y ago

I predict that there will be some kind of support for generics... eventually. Not explicitly in the language itself, but some added 'go generate' style tooling support. You will be able to define containers and such to use the empty interface, and add in some comments saying you want a version for strings, or floats. And the generate step will run to create the type-specific versions, which will then be compiled as usual. There's definitely work to be done in the details. This is my general read on where I think the community and developers are going... that's all.