5 ms·

Well, the fact is that many mainstream languages have Generics. You have an advantage to learn on others mistakes (e.g. made by those Java guys) and practice.

by zerr 11y ago

Well, the fact is that many mainstream languages have Generics. You have an advantage to learn on others mistakes (e.g. made by those Java guys) and practice. I understand that Go team are more "systems" persons rather than "languages" in general. Did you try to consult with Dart team? e.g. with Gilad Bracha. Maybe you should consider hiring some languages person in Go team.

davecheney 11y ago
> You have an advantage to learn on others mistakes (e.g. made by those Java guys) and practice. And the lesson learnt from studying other languages is "Don't add generics unless it's right for the language, even if that means choosing, on balance, to _NOT_ implement them at all".
- Jweb_Guru 11y ago
  Can you provide some examples of languages where people regret having implemented generics at all (as opposed to wishing they had been implemented in a different way)?
  - davecheney 11y ago
    Java is the obvious example that springs to mind. Because of the requirement to be backwards compatible with Java 1.4, all the type information is erased during compilation. The call for reified types in Java has been heard for over a decade now. C++ compile type templating is the cause of egregiously long compilation speeds. One of the original drivers for the creation of Go was the speed of C++ compilation. I don't think you can separate a desire that generics was implemented a different way in these examples from the regret that their current implementation causes.
    - jlouis 11y ago
      If you are willing to pay with execution speed, you can get fast compiles for generics. But C++ opted for fast execution speed and hence pay with long compile times. I'd much rather have fast compilation and slower execution and some kind of generics, but the current situation is that people are insanely attached to their pride in fast program execution.
      - james4k 11y ago
        This is a common argument, but too much software is painfully slow to use. It becomes a user experience problem.
- Dewie3 11y ago
  I thought the lesson was "adding generics after the point where you have to care about backwards compatibility is fraught with peril".
enneff 11y ago
Many members of the Go team have a background in languages, and are part of a greater community of software practitioners involved with language design. Of course they have discussed these topics extensively with many people; they do not exist inside a vacuum.
PopsiclePete 11y ago
It's just not an easy problem to solve. And I'm not convinced it has been already solved, much less solved correctly, in the vast majority of cases. This is legal(-ish) C++: template<typename T> T Add(T one, T two){ return one + two; } It's completely illegal in C#. And Java. Both have "generics". Both are wildly different. Then you have the Haskell camp which look at all of these "generics" and shake their heads and laugh bitterly since their static type system and "generic" blow all other ones out of the water anyway. So when you say you want "generics" - which flavor do you want? How does it play with Go's interfaces? How deep down the rabbit hole do you go? It's very easy, when you're not familiar with the problem to say "just do it" - but everyone seems to have their own idea of what "generics" is, how it works, how to constrain parameters, etc. So even if the Go team picked an implementation from Camp A, I'm 120% positive that camps B, C, D, and X would declare it the worst implementation ever, and again, they've pleased no-one. I'm glad they're sticking to their guns on this one. Show them an implementation that works in Go, and they've said multiple times they might do it. Put up or shut up, basically.
- codygman 11y ago
  > Show them an implementation that works in Go, and they've said multiple times they might do it. Put up or shut up, basically. Didn't someone fork Go and do exactly that only to get ignored? Perhaps it was a rumor, do you know? I'll see if I can find any reference to it.
  - dilap 11y ago
    That would be interesting to see. (I've never heard of such a thing...)
    - codygman 11y ago
      Best I could find was this: https://groups.google.com/forum/#!topic/golang-nuts/L5LothlvaCw https://groups.google.com/forum/#!topic/golang-nuts/L5Lothlv... It also led to a real world example where the author tried using Go for a project and had a lot of need for Generics: http://oneofmanyworlds.blogspot.com/2011/11/draft-2-of-proposal-for-generics-in-go.html http://oneofmanyworlds.blogspot.com/2011/11/draft-2-of-propo...

by zerr 11y ago

davecheney 11y ago

> You have an advantage to learn on others mistakes (e.g. made by those Java guys) and practice. And the lesson learnt from studying other languages is "Don't add generics unless it's right for the language, even if that means choosing, on balance, to _NOT_ implement them at all".

Jweb_Guru 11y ago
Can you provide some examples of languages where people regret having implemented generics at all (as opposed to wishing they had been implemented in a different way)?
- davecheney 11y ago
  Java is the obvious example that springs to mind. Because of the requirement to be backwards compatible with Java 1.4, all the type information is erased during compilation. The call for reified types in Java has been heard for over a decade now. C++ compile type templating is the cause of egregiously long compilation speeds. One of the original drivers for the creation of Go was the speed of C++ compilation. I don't think you can separate a desire that generics was implemented a different way in these examples from the regret that their current implementation causes.
  - jlouis 11y ago
    If you are willing to pay with execution speed, you can get fast compiles for generics. But C++ opted for fast execution speed and hence pay with long compile times. I'd much rather have fast compilation and slower execution and some kind of generics, but the current situation is that people are insanely attached to their pride in fast program execution.
    - james4k 11y ago
      This is a common argument, but too much software is painfully slow to use. It becomes a user experience problem.
Dewie3 11y ago
I thought the lesson was "adding generics after the point where you have to care about backwards compatibility is fraught with peril".

enneff 11y ago

Many members of the Go team have a background in languages, and are part of a greater community of software practitioners involved with language design. Of course they have discussed these topics extensively with many people; they do not exist inside a vacuum.

PopsiclePete 11y ago

It's just not an easy problem to solve. And I'm not convinced it has been already solved, much less solved correctly, in the vast majority of cases. This is legal(-ish) C++: template<typename T> T Add(T one, T two){ return one + two; } It's completely illegal in C#. And Java. Both have "generics". Both are wildly different. Then you have the Haskell camp which look at all of these "generics" and shake their heads and laugh bitterly since their static type system and "generic" blow all other ones out of the water anyway. So when you say you want "generics" - which flavor do you want? How does it play with Go's interfaces? How deep down the rabbit hole do you go? It's very easy, when you're not familiar with the problem to say "just do it" - but everyone seems to have their own idea of what "generics" is, how it works, how to constrain parameters, etc. So even if the Go team picked an implementation from Camp A, I'm 120% positive that camps B, C, D, and X would declare it the worst implementation ever, and again, they've pleased no-one. I'm glad they're sticking to their guns on this one. Show them an implementation that works in Go, and they've said multiple times they might do it. Put up or shut up, basically.

codygman 11y ago
> Show them an implementation that works in Go, and they've said multiple times they might do it. Put up or shut up, basically. Didn't someone fork Go and do exactly that only to get ignored? Perhaps it was a rumor, do you know? I'll see if I can find any reference to it.
- dilap 11y ago
  That would be interesting to see. (I've never heard of such a thing...)
  - codygman 11y ago
    Best I could find was this: https://groups.google.com/forum/#!topic/golang-nuts/L5LothlvaCw https://groups.google.com/forum/#!topic/golang-nuts/L5Lothlv... It also led to a real world example where the author tried using Go for a project and had a lot of need for Generics: http://oneofmanyworlds.blogspot.com/2011/11/draft-2-of-proposal-for-generics-in-go.html http://oneofmanyworlds.blogspot.com/2011/11/draft-2-of-propo...