5 ms·

What changed? Why is the Go team finally considering this now, when it has been requested for these exact reasons by many credible developers since Go's beginni

What changed? Why is the Go team finally considering this now, when it has been requested for these exact reasons by many credible developers since Go's beginning? EDIT: Yes, something has changed. They always said "no, but maybe later" and now it's "ok how about now". That is a big change and I am just asking what's the reason for it.

m_sahaf 8y ago
Nothing changed. It wasn't off the table to begin with. See: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics
- coldtea 8y ago
  The question of the parent boils down to "what put it on the menu". So, yeah, it was always "on the table" in some hazy, we'll see later, way, but not like that.
  - BurningCycles 8y ago
    Likely because they have now figured out implementations of these features which they feel work well with the rest of the language design.
  - sagichmal 8y ago
    I think a good faith reading of the circumstance would lead one to conclude that the passage of time, and other, higher-priority and lower-cost-of-implementation issues being addressed, have put these issues on the menu.
cridenour 8y ago
Because now is later than when they said later?
ianlancetaylor 8y ago
A year ago we said it was time to move toward Go 2: https://blog.golang.org/toward-go2 https://blog.golang.org/toward-go2 . This is another step in that direction.
- sdegutis 8y ago
  Then I'm a year late in asking why the Go team is now deciding to say yes to something they said no to for over half a decade.
  - ianlancetaylor 8y ago
    The blog post explains that.
derefr 8y ago
Adding generics is a major change (e.g. it would restructure the stdlib), and so it would only belong in a major-version bump of the language.
- kibwen 8y ago
  Though the authors have clarified that the "2" in "Go 2" is just for marketing purposes, and that the actual release would still be "Go 1.x", and shouldn't break any existing code (so it won't restructure the stdlib in any major way, unless they want to do a huge mass-deprecation).
  - sdegutis 8y ago
    So Go is following the exact same path as Java.
    - qznc 8y ago
      Inevitably. Also inevitably, Java will get value types (structs) at some point. Just like with Go Generics, people will complain the feature is bolted on. After some time it is just one of the many quirks of a complex language. I think it was Stroustrup who said: there are two kinds of programming languages, the ones people hate and the ones nobody uses.
      - pjmlp 8y ago
        And Java had quite a few good examples to take on like Modula-3 and Eiffel, but alas they wanted something for average Joe, kind of sounds familiar.
      - sdegutis 8y ago
        The difference is that Go could have learned from Java.
bsder 8y ago
> What changed? Why is the Go team finally considering this now, when it has been requested for these exact reasons by many credible developers since Go's beginning? Simply, Go has probably accumulated all the developers it is going to accumulate without something drastically changing. At this point, I can't think of any programmers around me who now want to learn Go.
mikekchar 8y ago
The reason for saying "no, but maybe later" originally was that it was always a desired piece of functionality. I believe the word "inevitable" was even tossed around. The problem was that they didn't like the existing implementations of generics in other languages and also didn't know how they would improve it. I haven't had time to look at the details, so I'm not sure what they actually did, but I think they basically came up with a strategy that they are mostly happy with. You might ask, why not pick a solution earlier and then improve it over time? However with a popular language it's not that easy. People are writing lots of code. If you start early, you can paint yourself in a corner and end up with a system that you really can't improve very much because it introduces incompatible changes. Note the extremely painful (and drawn out!) incompatible changes with Perl 6 and Python 3. If you make the wrong choice early, you might still take over a decade to find an opportunity to replace it. And since the state of the art in language design moves very slowly, it took a long time before they could see something that they felt they wouldn't regret choosing.
- mikekchar 8y ago
  I highly recommend reading https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf... This is part of the material linked to from this thread. It answers all your questions. You will see that some of the people who are directly replying to you are very much involved in this effort. Edit: I tried editing the previous message but HN actually automatically made a reply instead....
marcus_holmes 8y ago
I think because it would break backward compatability in v1, and not doing that was the Most Important Thing in all 1.xx releases. v2 is allowed to Break Stuff. So obviously they're going to consider the thing that people have shouted for most in Go... generics and error handling (and package management but they found a way of doing that earlier).

m_sahaf 8y ago

Nothing changed. It wasn't off the table to begin with. See: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics

coldtea 8y ago
The question of the parent boils down to "what put it on the menu". So, yeah, it was always "on the table" in some hazy, we'll see later, way, but not like that.
- BurningCycles 8y ago
  Likely because they have now figured out implementations of these features which they feel work well with the rest of the language design.
- sagichmal 8y ago
  I think a good faith reading of the circumstance would lead one to conclude that the passage of time, and other, higher-priority and lower-cost-of-implementation issues being addressed, have put these issues on the menu.

cridenour 8y ago

Because now is later than when they said later?

ianlancetaylor 8y ago

A year ago we said it was time to move toward Go 2: https://blog.golang.org/toward-go2 https://blog.golang.org/toward-go2 . This is another step in that direction.

sdegutis 8y ago
Then I'm a year late in asking why the Go team is now deciding to say yes to something they said no to for over half a decade.
- ianlancetaylor 8y ago
  The blog post explains that.

derefr 8y ago

Adding generics is a major change (e.g. it would restructure the stdlib), and so it would only belong in a major-version bump of the language.

kibwen 8y ago
Though the authors have clarified that the "2" in "Go 2" is just for marketing purposes, and that the actual release would still be "Go 1.x", and shouldn't break any existing code (so it won't restructure the stdlib in any major way, unless they want to do a huge mass-deprecation).
- sdegutis 8y ago
  So Go is following the exact same path as Java.
  - qznc 8y ago
    Inevitably. Also inevitably, Java will get value types (structs) at some point. Just like with Go Generics, people will complain the feature is bolted on. After some time it is just one of the many quirks of a complex language. I think it was Stroustrup who said: there are two kinds of programming languages, the ones people hate and the ones nobody uses.
    - pjmlp 8y ago
      And Java had quite a few good examples to take on like Modula-3 and Eiffel, but alas they wanted something for average Joe, kind of sounds familiar.
    - sdegutis 8y ago
      The difference is that Go could have learned from Java.

bsder 8y ago

> What changed? Why is the Go team finally considering this now, when it has been requested for these exact reasons by many credible developers since Go's beginning? Simply, Go has probably accumulated all the developers it is going to accumulate without something drastically changing. At this point, I can't think of any programmers around me who now want to learn Go.

mikekchar 8y ago

The reason for saying "no, but maybe later" originally was that it was always a desired piece of functionality. I believe the word "inevitable" was even tossed around. The problem was that they didn't like the existing implementations of generics in other languages and also didn't know how they would improve it. I haven't had time to look at the details, so I'm not sure what they actually did, but I think they basically came up with a strategy that they are mostly happy with. You might ask, why not pick a solution earlier and then improve it over time? However with a popular language it's not that easy. People are writing lots of code. If you start early, you can paint yourself in a corner and end up with a system that you really can't improve very much because it introduces incompatible changes. Note the extremely painful (and drawn out!) incompatible changes with Perl 6 and Python 3. If you make the wrong choice early, you might still take over a decade to find an opportunity to replace it. And since the state of the art in language design moves very slowly, it took a long time before they could see something that they felt they wouldn't regret choosing.

mikekchar 8y ago
I highly recommend reading https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf... This is part of the material linked to from this thread. It answers all your questions. You will see that some of the people who are directly replying to you are very much involved in this effort. Edit: I tried editing the previous message but HN actually automatically made a reply instead....

marcus_holmes 8y ago

I think because it would break backward compatability in v1, and not doing that was the Most Important Thing in all 1.xx releases. v2 is allowed to Break Stuff. So obviously they're going to consider the thing that people have shouted for most in Go... generics and error handling (and package management but they found a way of doing that earlier).