3 ms·

I completely agree. Although it's refreshing to have an official team leader mention generics as a priority rather than the passive-aggressive stance that used

by bsaul 7y ago

I completely agree. Although it's refreshing to have an official team leader mention generics as a priority rather than the passive-aggressive stance that used to be the norm a few years back (aka "show us why you need it, and give us a perfect design if you think that's possible). I think the "we're working on it, but it's going to take a lot of time before we get something good enough" current position is the perfect middleground.

deleted 7y ago
[deleted]
JulianMorrison 7y ago
If you look at the questionnaire[1] they ask for new changes, it's clear they still want a justification, and a design, for new proposals. And that proposals which "state a problem rather than a solution" will be rejected. It's just that they've been convinced that generics are justified. And they have concrete proposed solutions under evaluation. [1] https://github.com/golang/proposal/blob/master/go2-language-changes.md https://github.com/golang/proposal/blob/master/go2-language-...
- pansa2 7y ago
  > It's just that they've been convinced that generics are justified. I wonder if anybody’s actually changed their mind on this, or whether the opinion of the Go team has shifted simply because it’s made up of different people now.
  - mseepgood 7y ago
    There was no change of mind. They always had generics in their minds. See the Go FAQ: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics "Generics may well be added at some point. We don't feel an urgency for them [...] we continue to think about it. [...] The topic remains open." These sentences have been in the FAQ since Go 1.0. Maybe people should start to believe them. They have gathered experience with the current language, their generics design drafts have improved over the years, and now they feel like they have something that might fit.
  - typical182 7y ago
    As far as I have followed, I think it is more that while a fair amount of work had gone into prior designs for generics in Go, the general feeling of the core Go team was the prior designs did mesh well with the rest of the language, whereas the more recent design seems like it could work. From this blog post[1] from last year from the core Go team: We’ve been thinking about generics since work on Go began, and we wrote and rejected our first concrete design in 2010. We wrote and rejected three more designs by the end of 2013. Four abandoned experiments, but not failed experiments, We learned from them, like we learned from check and try. Each time, we learned that the path to Go 2 is not in that exact direction, and we noticed other directions that might be interesting to explore. But by 2013 we had decided that we needed to focus on other concerns, so we put the entire topic aside for a few years. Last year we started exploring and experimenting again, and we presented a new design, based on the idea of a contract, at Gophercon last summer. We’ve continued to experiment and simplify, and we’ve been working with programming language theory experts to understand the design better. Overall, I am hopeful that we’re headed in a good direction [1] https://blog.golang.org/experiment https://blog.golang.org/experiment
rob74 7y ago
AFAIK the position expressed in the Go FAQ (https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics) has always been the official position on generics: "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." There's nothing passive-aggressive about that - most proponents of generics only see the advantages (i.e. more expressiveness), but fail to see the downsides.
- bsaul 7y ago
  I think the "we're not doing it because it adds complexity in the type system and runtime" was something most developpers have a very hard time understanding, since generic programming exists in pratically every single PL created since C++. My understanding not just from the FAQ but also from reading conversation in the forums, was that they thought the feature itself had such a high potential of being misused as a crutch for bad designs that they thought not having generics was actually a feature. And to be honest i almost agree 100% with that perception. The problem is that it leads to archaism and copy pasting that make a few lines of codes here and there look just gross (although perfectly understandable).
  - pjmlp 7y ago
    It is even older than C++, CLU, ML had it first during the mid-70s, Ada and Modula-3 got it first in the early 80's, and C++ STL work actually was initially done in Ada.
  - danieldk 7y ago
    I think the "we're not doing it because it adds complexity in the type system and runtime" was something most developpers have a very hard time understanding, since generic programming exists in pratically every single PL created since C++. Plus, history has taught us that retrofitting generics to existing languages with their ecosystems can be difficult and painful (see Java and to some extend C++).
    - 7y ago
kyrra 7y ago
They have been iterating on the contracts proposal here: https://go-review.googlesource.com/c/go/+/187317 https://go-review.googlesource.com/c/go/+/187317

by bsaul 7y ago

deleted 7y ago

[deleted]

JulianMorrison 7y ago

If you look at the questionnaire[1] they ask for new changes, it's clear they still want a justification, and a design, for new proposals. And that proposals which "state a problem rather than a solution" will be rejected. It's just that they've been convinced that generics are justified. And they have concrete proposed solutions under evaluation. [1] https://github.com/golang/proposal/blob/master/go2-language-changes.md https://github.com/golang/proposal/blob/master/go2-language-...

pansa2 7y ago
> It's just that they've been convinced that generics are justified. I wonder if anybody’s actually changed their mind on this, or whether the opinion of the Go team has shifted simply because it’s made up of different people now.
- mseepgood 7y ago
  There was no change of mind. They always had generics in their minds. See the Go FAQ: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics "Generics may well be added at some point. We don't feel an urgency for them [...] we continue to think about it. [...] The topic remains open." These sentences have been in the FAQ since Go 1.0. Maybe people should start to believe them. They have gathered experience with the current language, their generics design drafts have improved over the years, and now they feel like they have something that might fit.
- typical182 7y ago
  As far as I have followed, I think it is more that while a fair amount of work had gone into prior designs for generics in Go, the general feeling of the core Go team was the prior designs did mesh well with the rest of the language, whereas the more recent design seems like it could work. From this blog post[1] from last year from the core Go team: We’ve been thinking about generics since work on Go began, and we wrote and rejected our first concrete design in 2010. We wrote and rejected three more designs by the end of 2013. Four abandoned experiments, but not failed experiments, We learned from them, like we learned from check and try. Each time, we learned that the path to Go 2 is not in that exact direction, and we noticed other directions that might be interesting to explore. But by 2013 we had decided that we needed to focus on other concerns, so we put the entire topic aside for a few years. Last year we started exploring and experimenting again, and we presented a new design, based on the idea of a contract, at Gophercon last summer. We’ve continued to experiment and simplify, and we’ve been working with programming language theory experts to understand the design better. Overall, I am hopeful that we’re headed in a good direction [1] https://blog.golang.org/experiment https://blog.golang.org/experiment

rob74 7y ago

AFAIK the position expressed in the Go FAQ (https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics) has always been the official position on generics: "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." There's nothing passive-aggressive about that - most proponents of generics only see the advantages (i.e. more expressiveness), but fail to see the downsides.

bsaul 7y ago
I think the "we're not doing it because it adds complexity in the type system and runtime" was something most developpers have a very hard time understanding, since generic programming exists in pratically every single PL created since C++. My understanding not just from the FAQ but also from reading conversation in the forums, was that they thought the feature itself had such a high potential of being misused as a crutch for bad designs that they thought not having generics was actually a feature. And to be honest i almost agree 100% with that perception. The problem is that it leads to archaism and copy pasting that make a few lines of codes here and there look just gross (although perfectly understandable).
- pjmlp 7y ago
  It is even older than C++, CLU, ML had it first during the mid-70s, Ada and Modula-3 got it first in the early 80's, and C++ STL work actually was initially done in Ada.
- danieldk 7y ago
  I think the "we're not doing it because it adds complexity in the type system and runtime" was something most developpers have a very hard time understanding, since generic programming exists in pratically every single PL created since C++. Plus, history has taught us that retrofitting generics to existing languages with their ecosystems can be difficult and painful (see Java and to some extend C++).
  - 7y ago

kyrra 7y ago

They have been iterating on the contracts proposal here: https://go-review.googlesource.com/c/go/+/187317 https://go-review.googlesource.com/c/go/+/187317