7 ms·

So now it turns out that generics are good?

rob74 5y ago
The Go team's stance on generics has never been "generics = bad", but "generics have advantages and disadvantages, and if we find an implementation which finds a good compromise between the advantages and disadvantages, we will do it". Which they now did. Let's hope it really turns out to be a good compromise...
- zerr 5y ago
  It was due to the arrogance and incompetence of a couple of ex-AT&T authorities in the team.
  - hu3 5y ago
    Is there a source for that? I ask because instances I read from the team were in the direction of: "We will gather enough use cases to decide on the matter".
    - gadflyinyoureye 5y ago
      While the GP was a bit...harsh, the main reason people have that view is generics, as a problem space, were solved. Java's way was published years ago. As was .NET's. Other languages exist which have some form generics. The argument of "gather enough use cases to decide on the matter" feels like a punt given the use cases already exist and were known in the industry for the past 30 years.
      - hu3 5y ago
        Perhaps. But in hindsight, Go's generics implementation turned different enough to warrant benefit of the doubt in my opinion. A notable difference is that Go interfaces are implicit while C# and Java are explicit and that affects Go generics.
      - rob74 5y ago
        The problem space may seem solved, but apparently it's still not as easy as it looks from the outside. You don't have to take my word for it, Cthulhu_ linked a comment by Russ Cox (a major contributor to Go) from a few years ago above: https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417 > We have spoken to a few true experts in Java generics and each of them has said roughly the same thing: be very careful, it's not as easy as it looks, and you're stuck with all the mistakes you make.
        gadflyinyoureye 5y ago
        I agree. From my Java experience most people don’t do a lot with them. List<Something> and the like. It makes things like boiler plate easier. I’m not saying it’s easy to implement. Rather the ideas are there and implementable. Typescript has them and it’s relatively young.
  - lowmagnet 5y ago
    It was due to the careful and deliberate nature of the Go team, and the backward compatibility guarantee. It took years for the group to put together a proposal with minimal changes to the runtime and core libraries, and this implementation in 1.18 will be limited in scope to only add the feature, waiting for future versions to update other core libraries to adapt generics in a backward-compatible way.
  - Cthulhu_ 5y ago
    Have you even looked at other languages' implementation of generics? Java's implementation takes up a significant part of the language spec, compiler, and VM for example. Here's an insightful comment from some time ago, explaining why it's a technical issue, not a political one: https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417 It links to this FAQ highlighting a LOT of the complexities and pitfalls of generics in Java, things that are all to easily overlooked by armchair language expert: http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#FAQ106 http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypePa.... Note that that's just one chapter in a very large document. Comments like this say more about their author's arrogance than that of the Go language team.
    - nauticacom 5y ago
      To me, "takes up a significant part of the language spec, compiler, and VM" isn't a meaningful reason to exclude something from a language, unless it's a hobby project. The job of languages, imo, is to provide tools/features/syntax for expressing problems, whether their implementation is complex or not. Ruby is an incredible language to use, but its implementation is notoriously hairy. That internal complexity is not something that matters to me in the slightest. I understand the Go team's reluctance to get the user-facing interface wrong, and end up with something like type-erasure in Java; that's slightly connected with implementation complexity, but saying "it's complex to implement and specify" doesn't seem enough to me. [edit: made it clearer that this is my thought on the job of languages and not some universal truth]
      - assbuttbuttass 5y ago
        I actually have a different view. One of the things I love about go is it's a simple language, and I can hold the whole language spec in my head while I'm programming. A generics implementation can't sacrifice the simplicity of the language, or make it any harder to read go code.
        nauticacom 5y ago
        I can hold the whole language spec in my head while I'm programming People love to say this about Go, but it's not something that, like, actually matters (and I doubt it's literally true). A language can be reasonably understandable such that you can effectively and productively program in it without being aggressively simple. Again, to use the case of Ruby, I might not remember every single syntactical construct or handling of every edge case, but the language is reasonably understandable such that I can write programs without constantly asking "what was the syntax for that?" or "how do I express this?" As a counter-example, I think the complexity of C++ is not just limited to its implementation, and leaks out to its interface. ...sacrifice the simplicity of the language, or make it any harder to read go code These are two separate concerns which, while somewhat related, are not directly correlated. A simple language can make it more obvious which syntactical constructs are being used and what literal operations are being performed, but there are many more dimensions to reading code than just those.
mfrw 5y ago
It remains to bee seen, meanwhile Rob Pike did comment[0], we should refrain from changing libraries in 1.18 immediately after generics are in. "The reason is simple and compelling: It's too much to do all at once, and we might get it wrong." [0]: https://github.com/golang/go/issues/48918 https://github.com/golang/go/issues/48918
- Cthulhu_ 5y ago
  > It's too much to do all at once, and we might get it wrong. If only people realized this about most software projects. There's a lot of hubris and under-estimation in software engineering.

The Go team's stance on generics has never been "generics = bad", but "generics have advantages and disadvantages, and if we find an implementation which finds a good compromise between the advantages and disadvantages, we will do it". Which they now did. Let's hope it really turns out to be a good compromise...

zerr 5y ago
It was due to the arrogance and incompetence of a couple of ex-AT&T authorities in the team.
- hu3 5y ago
  Is there a source for that? I ask because instances I read from the team were in the direction of: "We will gather enough use cases to decide on the matter".
  - gadflyinyoureye 5y ago
    While the GP was a bit...harsh, the main reason people have that view is generics, as a problem space, were solved. Java's way was published years ago. As was .NET's. Other languages exist which have some form generics. The argument of "gather enough use cases to decide on the matter" feels like a punt given the use cases already exist and were known in the industry for the past 30 years.
    - hu3 5y ago
      Perhaps. But in hindsight, Go's generics implementation turned different enough to warrant benefit of the doubt in my opinion. A notable difference is that Go interfaces are implicit while C# and Java are explicit and that affects Go generics.
    - rob74 5y ago
      The problem space may seem solved, but apparently it's still not as easy as it looks from the outside. You don't have to take my word for it, Cthulhu_ linked a comment by Russ Cox (a major contributor to Go) from a few years ago above: https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417 > We have spoken to a few true experts in Java generics and each of them has said roughly the same thing: be very careful, it's not as easy as it looks, and you're stuck with all the mistakes you make.
      - gadflyinyoureye 5y ago
        I agree. From my Java experience most people don’t do a lot with them. List<Something> and the like. It makes things like boiler plate easier. I’m not saying it’s easy to implement. Rather the ideas are there and implementable. Typescript has them and it’s relatively young.
- lowmagnet 5y ago
  It was due to the careful and deliberate nature of the Go team, and the backward compatibility guarantee. It took years for the group to put together a proposal with minimal changes to the runtime and core libraries, and this implementation in 1.18 will be limited in scope to only add the feature, waiting for future versions to update other core libraries to adapt generics in a backward-compatible way.
- Cthulhu_ 5y ago
  Have you even looked at other languages' implementation of generics? Java's implementation takes up a significant part of the language spec, compiler, and VM for example. Here's an insightful comment from some time ago, explaining why it's a technical issue, not a political one: https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417 It links to this FAQ highlighting a LOT of the complexities and pitfalls of generics in Java, things that are all to easily overlooked by armchair language expert: http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#FAQ106 http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypePa.... Note that that's just one chapter in a very large document. Comments like this say more about their author's arrogance than that of the Go language team.
  - nauticacom 5y ago
    To me, "takes up a significant part of the language spec, compiler, and VM" isn't a meaningful reason to exclude something from a language, unless it's a hobby project. The job of languages, imo, is to provide tools/features/syntax for expressing problems, whether their implementation is complex or not. Ruby is an incredible language to use, but its implementation is notoriously hairy. That internal complexity is not something that matters to me in the slightest. I understand the Go team's reluctance to get the user-facing interface wrong, and end up with something like type-erasure in Java; that's slightly connected with implementation complexity, but saying "it's complex to implement and specify" doesn't seem enough to me. [edit: made it clearer that this is my thought on the job of languages and not some universal truth]
    - assbuttbuttass 5y ago
      I actually have a different view. One of the things I love about go is it's a simple language, and I can hold the whole language spec in my head while I'm programming. A generics implementation can't sacrifice the simplicity of the language, or make it any harder to read go code.
      - nauticacom 5y ago
        I can hold the whole language spec in my head while I'm programming People love to say this about Go, but it's not something that, like, actually matters (and I doubt it's literally true). A language can be reasonably understandable such that you can effectively and productively program in it without being aggressively simple. Again, to use the case of Ruby, I might not remember every single syntactical construct or handling of every edge case, but the language is reasonably understandable such that I can write programs without constantly asking "what was the syntax for that?" or "how do I express this?" As a counter-example, I think the complexity of C++ is not just limited to its implementation, and leaks out to its interface. ...sacrifice the simplicity of the language, or make it any harder to read go code These are two separate concerns which, while somewhat related, are not directly correlated. A simple language can make it more obvious which syntactical constructs are being used and what literal operations are being performed, but there are many more dimensions to reading code than just those.

mfrw 5y ago

It remains to bee seen, meanwhile Rob Pike did comment[0], we should refrain from changing libraries in 1.18 immediately after generics are in. "The reason is simple and compelling: It's too much to do all at once, and we might get it wrong." [0]: https://github.com/golang/go/issues/48918 https://github.com/golang/go/issues/48918

Cthulhu_ 5y ago
> It's too much to do all at once, and we might get it wrong. If only people realized this about most software projects. There's a lot of hubris and under-estimation in software engineering.