8 ms·

Several members of the Go team have invested significant effort in studying generics and designing proposals, since before Go 1.0. For example, Ian Lance Taylor

Several members of the Go team have invested significant effort in studying generics and designing proposals, since before Go 1.0. For example, Ian Lance Taylor published several of his previous efforts, which had shortcomings he was dissatisfied with. I believe your impression of the Go team's position has been corrupted (likely unintentionally) by intermediaries.

kyrra 9y ago
Link to top-level proposal: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-... If you scroll to the bottom, you can see 4 large proposals written by Ian over the years.
pjmlp 9y ago
Except they seem to focus only on Java, .NET and C++, forgetting that generics were initially implemented in CLU back in 1975, and there were several programming languages since those days that had some form of generics being designed into them.
- masklinn 9y ago
  > Except they seem to focus only on Java, .NET and C++ C# isn't mentioned in any of the previous proposals, only Java, C++ and C.
  - _old_dude_ 9y ago
    C# does generics specialization at runtime, hard to do if you have no JIT :)
    - davidp 9y ago
      Thanks for the tip, you made me go google some things! [0] Do you need a full-on JIT, or just a runtime? [1] [0]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/differences-between-cpp-templates-and-csharp-generics https://docs.microsoft.com/en-us/dotnet/csharp/programming-g... [1]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/generics-in-the-run-time https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
      - AlphaSite 9y ago
        As I understand it it’s JIT in name only, doing the compilation on first run and then never again.
        pjmlp 9y ago
        That is also a JIT, dynamic compilation doesn't require recompiling the code all the time. The AS/400 uses a kernel level JIT, binaries are only JITted at installation time or explicitly via the command line. The Lisp environments also only used JIT once. Some implementations of Oberon would use bytecode instead of native code and JIT on module load. There are many other examples.
- vram22 9y ago
  Any thoughts on Eiffel's implementation of generics? https://en.wikipedia.org/wiki/Eiffel_(programming_language)#Genericity https://en.wikipedia.org/wiki/Eiffel_(programming_language)#...
  - pjmlp 9y ago
    I liked using it at the university back in the day, and didn't had to repeat code. Eiffel is a very powerfull language with good tooling, just failed adoption, because licenses were too expensive and software industry still has issues valuing quality.
    - vram22 9y ago
      Interesting to hear your experience. I had read a good amount about Eiffel and also large parts of Bertrand Meyer's book Object-Oriented Software Construction (quite a thick book too, and which uses the syntax and semantics of Eiffel, or something close to it, IIRC [1]), some years ago. Had found the language very interesting and also was impressed by it (and by the book). Read some case studies / success stories about it, which were good too. He and his team seem to have taken a lot of pains and thought a lot about the design as well as implementation of the language, from both an academic and industrial use perspective - so it seemed to me. There is also an interesting anecdote about use of Eiffel in the book, here: https://en.wikipedia.org/wiki/Object-Oriented_Software_Construction#Notation https://en.wikipedia.org/wiki/Object-Oriented_Software_Const... That section shows the the 1st edition of the book did use Eiffel (as I said above).
      - pjmlp 9y ago
        With Eiffel tools you got the IDE with interactive development, including a VM for rapid prototyping. Then you would use the AOT compiler (via compilation to C) to produce shippable binaries. So combining the easiness of interactive development with performance when it was time to ship the product. It was also available before Java was a thing. This is what I always kind of missed with Java and .NET, the previous generation of languages (Eiffel, Modula-3, Oberon(-2)) all had a mix of interactive development and AOT compilation for shipping release builds.
- rsc 9y ago
  FWIW I have Liskov and Guttag (1986) on my desk. I haven't forgotten. I also explicitly address the "several since those days" in https://research.swtch.com/go2017#generics https://research.swtch.com/go2017#generics.
wwweston 9y ago
While "fuck generics" might be a low-resolution characterization, it's not entirely inaccurate, and the efforts of Taylor (and perhaps others) notwithstanding, as long as anyone is writing things like "I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve," there's reason to believe it's apt enough. As other respondents to the GP comment show, it's not at all hard to come up with that ostensibly elusive picture if you're attending to it. So I suppose the obvious takeaway is that they're still not really attending to it. Which is fine, Go clearly has its niche and its fans, and people who don't want a pretty good Blub have other options.
- skybrian 9y ago
  This is frustrating. Substituting an insult for politely declining (while leaving the door open) is not "low-resolution" or "apt enough", it's almost entirely inaccurate. Politeness matters.
  - wwweston 9y ago
    "low resolution" is a perfectly accurate description of "fuck generics", which like any two-word phrase can't entirely capture the attitude of the golang team, but nevertheless does seem to capture something of gestalt of their approach. Finer resolution would be if fusiongyro had characterized the golang team as saying "fuck off developers who want generics," which wouldn't have been as polite as the phrase "I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve," but whose semantics are otherwise equivalent.
    - skybrian 9y ago
      No. Unless someone finds a quote, the low order bit is that they didn't use the word "fuck" or any other swear word at all. You can't use the word "fuck" to accurately quote someone who didn't use that word.
      - wwweston 9y ago
sbov 9y ago
Did he compare those shortcomings with the shortcomings of not implementing generics at all? Because that is the tradeoff here. After decades of research, a decade of go, millions of lines of public and private code, a decade of feedback, and dozens of languages with generics, it's obvious that the perfect generic system isn't going to just happen, so it's not perfect generics vs imperfect generics, it's no generics vs imperfect generics.
e12e 9y ago
This made me wonder if there's been efforts to fork golang and add generics as a proof of concept? In theory it should be much easier than a few of the crazy things people have done with c over the years?
- pjmlp 9y ago
  It would be an wasted effort given the community's high resistance to them, better spend those hours contributing to a project where users value the work given for free.

kyrra 9y ago

Link to top-level proposal: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-... If you scroll to the bottom, you can see 4 large proposals written by Ian over the years.

pjmlp 9y ago

Except they seem to focus only on Java, .NET and C++, forgetting that generics were initially implemented in CLU back in 1975, and there were several programming languages since those days that had some form of generics being designed into them.

masklinn 9y ago
> Except they seem to focus only on Java, .NET and C++ C# isn't mentioned in any of the previous proposals, only Java, C++ and C.
- _old_dude_ 9y ago
  C# does generics specialization at runtime, hard to do if you have no JIT :)
  - davidp 9y ago
    Thanks for the tip, you made me go google some things! [0] Do you need a full-on JIT, or just a runtime? [1] [0]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/differences-between-cpp-templates-and-csharp-generics https://docs.microsoft.com/en-us/dotnet/csharp/programming-g... [1]: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/generics-in-the-run-time https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
    - AlphaSite 9y ago
      As I understand it it’s JIT in name only, doing the compilation on first run and then never again.
      - pjmlp 9y ago
        That is also a JIT, dynamic compilation doesn't require recompiling the code all the time. The AS/400 uses a kernel level JIT, binaries are only JITted at installation time or explicitly via the command line. The Lisp environments also only used JIT once. Some implementations of Oberon would use bytecode instead of native code and JIT on module load. There are many other examples.
vram22 9y ago
Any thoughts on Eiffel's implementation of generics? https://en.wikipedia.org/wiki/Eiffel_(programming_language)#Genericity https://en.wikipedia.org/wiki/Eiffel_(programming_language)#...
- pjmlp 9y ago
  I liked using it at the university back in the day, and didn't had to repeat code. Eiffel is a very powerfull language with good tooling, just failed adoption, because licenses were too expensive and software industry still has issues valuing quality.
  - vram22 9y ago
    Interesting to hear your experience. I had read a good amount about Eiffel and also large parts of Bertrand Meyer's book Object-Oriented Software Construction (quite a thick book too, and which uses the syntax and semantics of Eiffel, or something close to it, IIRC [1]), some years ago. Had found the language very interesting and also was impressed by it (and by the book). Read some case studies / success stories about it, which were good too. He and his team seem to have taken a lot of pains and thought a lot about the design as well as implementation of the language, from both an academic and industrial use perspective - so it seemed to me. There is also an interesting anecdote about use of Eiffel in the book, here: https://en.wikipedia.org/wiki/Object-Oriented_Software_Construction#Notation https://en.wikipedia.org/wiki/Object-Oriented_Software_Const... That section shows the the 1st edition of the book did use Eiffel (as I said above).
    - pjmlp 9y ago
      With Eiffel tools you got the IDE with interactive development, including a VM for rapid prototyping. Then you would use the AOT compiler (via compilation to C) to produce shippable binaries. So combining the easiness of interactive development with performance when it was time to ship the product. It was also available before Java was a thing. This is what I always kind of missed with Java and .NET, the previous generation of languages (Eiffel, Modula-3, Oberon(-2)) all had a mix of interactive development and AOT compilation for shipping release builds.
rsc 9y ago
FWIW I have Liskov and Guttag (1986) on my desk. I haven't forgotten. I also explicitly address the "several since those days" in https://research.swtch.com/go2017#generics https://research.swtch.com/go2017#generics.

wwweston 9y ago

While "fuck generics" might be a low-resolution characterization, it's not entirely inaccurate, and the efforts of Taylor (and perhaps others) notwithstanding, as long as anyone is writing things like "I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve," there's reason to believe it's apt enough. As other respondents to the GP comment show, it's not at all hard to come up with that ostensibly elusive picture if you're attending to it. So I suppose the obvious takeaway is that they're still not really attending to it. Which is fine, Go clearly has its niche and its fans, and people who don't want a pretty good Blub have other options.

skybrian 9y ago
This is frustrating. Substituting an insult for politely declining (while leaving the door open) is not "low-resolution" or "apt enough", it's almost entirely inaccurate. Politeness matters.
- wwweston 9y ago
  "low resolution" is a perfectly accurate description of "fuck generics", which like any two-word phrase can't entirely capture the attitude of the golang team, but nevertheless does seem to capture something of gestalt of their approach. Finer resolution would be if fusiongyro had characterized the golang team as saying "fuck off developers who want generics," which wouldn't have been as polite as the phrase "I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve," but whose semantics are otherwise equivalent.
  - skybrian 9y ago
    No. Unless someone finds a quote, the low order bit is that they didn't use the word "fuck" or any other swear word at all. You can't use the word "fuck" to accurately quote someone who didn't use that word.
    - wwweston 9y ago

sbov 9y ago

Did he compare those shortcomings with the shortcomings of not implementing generics at all? Because that is the tradeoff here. After decades of research, a decade of go, millions of lines of public and private code, a decade of feedback, and dozens of languages with generics, it's obvious that the perfect generic system isn't going to just happen, so it's not perfect generics vs imperfect generics, it's no generics vs imperfect generics.

e12e 9y ago

This made me wonder if there's been efforts to fork golang and add generics as a proof of concept? In theory it should be much easier than a few of the crazy things people have done with c over the years?

pjmlp 9y ago
It would be an wasted effort given the community's high resistance to them, better spend those hours contributing to a project where users value the work given for free.