11 ms·

Am I the only one who’s absolutely shocked that Go finally is embracing generics? Does anyone have a bit of an inside view into what changed in the perspective

Am I the only one who’s absolutely shocked that Go finally is embracing generics? Does anyone have a bit of an inside view into what changed in the perspectives of the language maintainers? I’m not buying the “it took us 20 years to understand how to do it correctly” argument, as this is something you explicitly take into consideration when designing the language or not. And it was specifically not a part of language design, and is much harder to retrofit (backwards compatibility). So what changed?

throw2ih020 2mo ago
> what changed in the perspectives of the language maintainers? The original maintainers moved on to other projects and the new community maintainers came to a consensus through the proposal and governance process.
- bradfitz 2mo ago
  No, that's not accurate. The same core people were involved.
bradfitz 2mo ago
(I was on the Go team for ages) Seriously, that's all it was. Just Ian alone proposed and rejected a half dozen of his own different approaches to generics. Finally a language + implementation plan came together that people all liked. Nobody was ever opposed to generics that I saw.
- lowmagnet 2mo ago
  The implementation is coming along nicely, and I'm already thinking of ways of using generic bound functions. I'm not bad that it's not like Java 1.4 despite having the lessons of Java 1.4, but being class-based is a very different way of working from go. Getting the unbound functions right before the bound ones was a struggle, but I do think the approach makes sense, in the long run. I can't wait to see the Container stuff in the next iteration, too.
fooster 2mo ago
It’s also not true that because it wasn’t part of the initial design that it was harder to retrofit. I just don’t understand all this go bashing that happens on this site especially when so much is badly informed speculation. I guess it’s easier to tear something down.
- stingraycharles 2mo ago
  my post was never intended as Go bashing, I use Go a lot and appreciate its simplicity. am I tearing something down in my comment?
  - foldr 2mo ago
    HN threads on Go are boring because they always get derailed by someone grousing about the fact that it took a long time to add generics. The history of this has been gone over a thousand times already and it’s really quite undramatic. The Go team couldn’t figure out a good design for generics for a long time. Eventually, they got some help from Phil Wadler and other type system experts and figured it out. The end. Anyone who feels that the Go team should have done it faster owes us at the very least their own design together with a soundness proof for a plausible fragment of Go. Conspicuously, no-one provided such a thing before the Go team did. The details of Go generics, their advantages and disadvantages compared to other languages, etc., are absolutely interesting to discuss. But there is nothing hiding behind the “official” story.
amtamt 2mo ago
If bug free binary search implementation can take 16 years, I am ready to buy generics implementation could take 20 years. > In his landmark book The Art of Computer Programming, legendary computer scientist Donald Knuth noted that although the first binary search algorithm was published by John Mauchly in 1946, the first bug-free version was not published until 1962—taking a staggering 16 years to get right.
- ckcheng 2mo ago
  Took a few more years to get really bug free. > Fast forward to 2006. I was shocked to learn that the binary search program that Bentley proved correct and subsequently tested in Chapter 5 of Programming Pearls contains a bug. ... Lest you think I'm picking on Bentley, let me tell you how I discovered the bug: The version of binary search that I wrote for the JDK contained the same bug. It was reported to Sun recently when it broke someone's program, after lying in wait for nine years or so. https://research.google/blog/extra-extra-read-all-about-it-nearly-all-binary-searches-and-mergesorts-are-broken/ https://research.google/blog/extra-extra-read-all-about-it-n...
  - inigyou 2mo ago
    403 error. What was the bug?
    - _dain_ 2mo ago
      IIRC it was overflow when you do (a + b) / 2 for the midpoint. It took so long to find because you need a >billion item array to overflow the 32-bit integer, and that much RAM wasn't common until the 00s. The right way is a + (b - a)/2.
      - inigyou 2mo ago
        64KiB was common in the 16-bit era, however
    - fragmede 2mo ago
whateveracct 2mo ago
and they're still worse than the 1970s state of the art lol
- eager_learner 2mo ago
  you mean like in Oberon?
  - whateveracct 2mo ago
    ML's parametric polymorphism
    - foldr 2mo ago
      Go lets you constrain type parameters with interfaces. To do anything analagous in SML you have to use functors, which is substantially less convenient. I think people who refer to ML's parametric polymorphism in this context must really be thinking of parametric polymorphism in OCaml or Haskell.
      - whateveracct 2mo ago
        You just do dictionary passing.
        foldr 2mo ago
        Like this, you mean? https://haskellforall.com/2012/05/scrap-your-type-classes https://haskellforall.com/2012/05/scrap-your-type-classes Fine in principle, but AFAIK it never really caught on because the ergonomics suck. Interfaces/traits/type classes do seem to be a popular feature across languages, for what it's worth.
        whateveracct 2mo ago
        right but type classes are basically vtables aka dictionary passing but the compiler figures out which dictionary to summon for you but the key is they build seamlessly on top of real parametric polymorphism. you still get a real "forall a." in your proposition language. Go fucked up early on with their core language design due to an inability to learn from the 1970s so now it's terminally dookie sadly
abtinf 2mo ago
Unfortunately nothing changed. They wanted generics all along. The Go ecosystem was a delicate, special thing. It was a wholesale rejection of the malignant consultancy takeover of programming that had festered and spread for the previous 15 years. Introducing generics was a grievous error, and they just keep making it worse. It used to be you could look at any Go code from any author and pretty much instantly understand it completely. That’s no longer the case. It used to be you would work on a problem, just writing the code from top to bottom. No time wasted fiddling with abstractions you’ll never use. You’d grumble about it, but succumbing to the temptation was impossible. That’s no longer the case.
- tacitusarc 2mo ago
  I have written Go for the past decade and completely, fundamentally disagree with this take. Go has always had a tendency towards limited exressivity, which created a strong dependence on interface{}, type assertions, and runtime bug’s that should have been compiler errors. When I read these grumbling takes about how Go use to be so simple etc I imagine devs who would revel in all the features they were unable to implement because it would be too difficult in the language. Or devs who love typing and re-typing the same code over and over again, littering their code with switch cases and conditional logic while passing themselves on the back for avoiding “abstraction”.
  - wredcoll 2mo ago
    [dead]
HumblyTossed 2mo ago
Surely it was pressure from devs to make Go look like every other language they begged to change then abandoned for the new hotness.
win311fwg 2mo ago
> Am I the only one who’s absolutely shocked that Go finally is embracing generics? Yes. Everyone else knows that they were always expected to be included at some point, as told when Go was first announced to the world: https://www.youtube.com/watch?v=rKnDgT73v8s&t=3267s https://www.youtube.com/watch?v=rKnDgT73v8s&t=3267s > So what changed? Philip Wadler, of Haskell fame, decided to help? This was well publicized on HN at the time. > I’m not buying the “it took us 20 years to understand how to do it correctly” argument If I recall correctly, Pike suggested that they never would have been able to come to that understanding without the outside help. I can understand why you are surprised that it took 20 years for someone with the right expertise to show up. You can get the sense in the above announcement that even the Go team thought that open sourcing the project would attract the right talent far, far earlier. But, now that we have hindsight, we can see that all the experts on HN who could have been the missing positive contributor were too busy complaining that Go didn't have generics. There wasn't enough time left for them to lend a hand. There are only so many hours in the day.

throw2ih020 2mo ago

> what changed in the perspectives of the language maintainers? The original maintainers moved on to other projects and the new community maintainers came to a consensus through the proposal and governance process.

bradfitz 2mo ago
No, that's not accurate. The same core people were involved.

bradfitz 2mo ago

(I was on the Go team for ages) Seriously, that's all it was. Just Ian alone proposed and rejected a half dozen of his own different approaches to generics. Finally a language + implementation plan came together that people all liked. Nobody was ever opposed to generics that I saw.

lowmagnet 2mo ago
The implementation is coming along nicely, and I'm already thinking of ways of using generic bound functions. I'm not bad that it's not like Java 1.4 despite having the lessons of Java 1.4, but being class-based is a very different way of working from go. Getting the unbound functions right before the bound ones was a struggle, but I do think the approach makes sense, in the long run. I can't wait to see the Container stuff in the next iteration, too.

fooster 2mo ago

It’s also not true that because it wasn’t part of the initial design that it was harder to retrofit. I just don’t understand all this go bashing that happens on this site especially when so much is badly informed speculation. I guess it’s easier to tear something down.

stingraycharles 2mo ago
my post was never intended as Go bashing, I use Go a lot and appreciate its simplicity. am I tearing something down in my comment?
- foldr 2mo ago
  HN threads on Go are boring because they always get derailed by someone grousing about the fact that it took a long time to add generics. The history of this has been gone over a thousand times already and it’s really quite undramatic. The Go team couldn’t figure out a good design for generics for a long time. Eventually, they got some help from Phil Wadler and other type system experts and figured it out. The end. Anyone who feels that the Go team should have done it faster owes us at the very least their own design together with a soundness proof for a plausible fragment of Go. Conspicuously, no-one provided such a thing before the Go team did. The details of Go generics, their advantages and disadvantages compared to other languages, etc., are absolutely interesting to discuss. But there is nothing hiding behind the “official” story.

amtamt 2mo ago

If bug free binary search implementation can take 16 years, I am ready to buy generics implementation could take 20 years. > In his landmark book The Art of Computer Programming, legendary computer scientist Donald Knuth noted that although the first binary search algorithm was published by John Mauchly in 1946, the first bug-free version was not published until 1962—taking a staggering 16 years to get right.

ckcheng 2mo ago
Took a few more years to get really bug free. > Fast forward to 2006. I was shocked to learn that the binary search program that Bentley proved correct and subsequently tested in Chapter 5 of Programming Pearls contains a bug. ... Lest you think I'm picking on Bentley, let me tell you how I discovered the bug: The version of binary search that I wrote for the JDK contained the same bug. It was reported to Sun recently when it broke someone's program, after lying in wait for nine years or so. https://research.google/blog/extra-extra-read-all-about-it-nearly-all-binary-searches-and-mergesorts-are-broken/ https://research.google/blog/extra-extra-read-all-about-it-n...
- inigyou 2mo ago
  403 error. What was the bug?
  - _dain_ 2mo ago
    IIRC it was overflow when you do (a + b) / 2 for the midpoint. It took so long to find because you need a >billion item array to overflow the 32-bit integer, and that much RAM wasn't common until the 00s. The right way is a + (b - a)/2.
    - inigyou 2mo ago
      64KiB was common in the 16-bit era, however
  - fragmede 2mo ago

whateveracct 2mo ago

and they're still worse than the 1970s state of the art lol

eager_learner 2mo ago
you mean like in Oberon?
- whateveracct 2mo ago
  ML's parametric polymorphism
  - foldr 2mo ago
    Go lets you constrain type parameters with interfaces. To do anything analagous in SML you have to use functors, which is substantially less convenient. I think people who refer to ML's parametric polymorphism in this context must really be thinking of parametric polymorphism in OCaml or Haskell.
    - whateveracct 2mo ago
      You just do dictionary passing.
      - foldr 2mo ago
        Like this, you mean? https://haskellforall.com/2012/05/scrap-your-type-classes https://haskellforall.com/2012/05/scrap-your-type-classes Fine in principle, but AFAIK it never really caught on because the ergonomics suck. Interfaces/traits/type classes do seem to be a popular feature across languages, for what it's worth.
        whateveracct 2mo ago
        right but type classes are basically vtables aka dictionary passing but the compiler figures out which dictionary to summon for you but the key is they build seamlessly on top of real parametric polymorphism. you still get a real "forall a." in your proposition language. Go fucked up early on with their core language design due to an inability to learn from the 1970s so now it's terminally dookie sadly

abtinf 2mo ago

Unfortunately nothing changed. They wanted generics all along. The Go ecosystem was a delicate, special thing. It was a wholesale rejection of the malignant consultancy takeover of programming that had festered and spread for the previous 15 years. Introducing generics was a grievous error, and they just keep making it worse. It used to be you could look at any Go code from any author and pretty much instantly understand it completely. That’s no longer the case. It used to be you would work on a problem, just writing the code from top to bottom. No time wasted fiddling with abstractions you’ll never use. You’d grumble about it, but succumbing to the temptation was impossible. That’s no longer the case.

tacitusarc 2mo ago
I have written Go for the past decade and completely, fundamentally disagree with this take. Go has always had a tendency towards limited exressivity, which created a strong dependence on interface{}, type assertions, and runtime bug’s that should have been compiler errors. When I read these grumbling takes about how Go use to be so simple etc I imagine devs who would revel in all the features they were unable to implement because it would be too difficult in the language. Or devs who love typing and re-typing the same code over and over again, littering their code with switch cases and conditional logic while passing themselves on the back for avoiding “abstraction”.
- wredcoll 2mo ago
  [dead]

HumblyTossed 2mo ago

Surely it was pressure from devs to make Go look like every other language they begged to change then abandoned for the new hotness.

win311fwg 2mo ago

> Am I the only one who’s absolutely shocked that Go finally is embracing generics? Yes. Everyone else knows that they were always expected to be included at some point, as told when Go was first announced to the world: https://www.youtube.com/watch?v=rKnDgT73v8s&t=3267s https://www.youtube.com/watch?v=rKnDgT73v8s&t=3267s > So what changed? Philip Wadler, of Haskell fame, decided to help? This was well publicized on HN at the time. > I’m not buying the “it took us 20 years to understand how to do it correctly” argument If I recall correctly, Pike suggested that they never would have been able to come to that understanding without the outside help. I can understand why you are surprised that it took 20 years for someone with the right expertise to show up. You can get the sense in the above announcement that even the Go team thought that open sourcing the project would attract the right talent far, far earlier. But, now that we have hindsight, we can see that all the experts on HN who could have been the missing positive contributor were too busy complaining that Go didn't have generics. There wasn't enough time left for them to lend a hand. There are only so many hours in the day.