4 ms·

My favorite thing about the core Go team is their willingness to say "No" (to all sorts of stuff) and "Wait for the right implementation" (for generics). I'm a

My favorite thing about the core Go team is their willingness to say "No" (to all sorts of stuff) and "Wait for the right implementation" (for generics). I'm a computational biologist rather than a programmer, so my use of Go waxes and wanes, but when I come back to Go, my code compiles and the language works the way I expect. That being said, I do appreciate Rob Pike's willingness to admit mistakes on the learning curve on community engagement without capitulating on adding all the shiny objects.

zozbot234 3y ago
Wrt. generics they followed in Java's footsteps: they asked the PLT community to come up with a reasonably elegant model that would mesh well with the rest of the language, and then largely stuck to that.
- erik_seaberg 3y ago
  It took years to root out and torch flawed APIs from the JVM ecosystem. After that example, it’s hard to defend neglecting the problem again and launching with no solution.
  - zdragnar 3y ago
    No language launches perfectly. If the cost of adding generics later is "existing code still works, and now this can work too" versus "the old version of genetics is flawed, burn everything down and use this version instead" or "generics didn't work out the way we wanted, use this new thing that's totally-not-generics-wink-wink"... Well, I'd say waiting is the right call. You're already used to adding three extra lines of boilerplate after every single line of code for error handling, living without generics wasn't that hard. Hell, I recall half the go community was convinced they weren't needed at all by the time they came around.
    - masklinn 3y ago
      > No language launches perfectly. There's a gulf between "not launching perfectly" and launching with obvious, blatant deficiencies. Go did the latter. Generics were always going to have to be implemented eventually, at least two languages in basically the space Go was targeting had had to bite that bullet in the decade before it was published. Support for third-party external dependencies only made that more dire. Instead of doing the work up-front and launching with generics, they decided to launch with ad-hoc generic builtins and "lalala can't hear you" for a decade, then finally implement half-assed generics.
    - kaba0 3y ago
      Languages are not created in a vacuum, or at least sane ones are not. Go failed to take into account the last 50 years of PL design, and it shows in its ridiculous number of shortcomings.
  - philosopher1234 3y ago
    The idea that it would be better if go waited an additional year or two to launch with generics is laughable. That extra year probably makes the difference for the languages success.
    - erik_seaberg 3y ago
      If you mean that another language with more planning might have caught on, I think that would have been a better outcome.
      - philosopher1234 3y ago
        Why would a better planned language win and not one that rushed and beat go to the finish?
        valenterry 3y ago
        That's not what he said. He said IF that WOULD have happened, it would have been better for everyone except for the Go designers.
        philosopher1234 3y ago
        My point is that if you delayed the release of Go, there’s no reason to believe you end up with a better world. So his argument is bunk.
        valenterry 3y ago
        Why not? I think his reasoning makes sense. Unless you mean that having a language with better design (but being released later) is not an improvement.
        philosopher1234 3y ago
        My argument is that timing is very important to adoption. Unix is not the best OS to have been designed by far, but it was the first free one. If go had been delayed, something else may have filled the slot, and there’s no reason to believe it would have been a better something else. I.e when Go did release 2 years later, but with generics, it’d be too late, and no one would care.
- thayne 3y ago
  I think that generics is really difficult to do well when added to a language later. At the very least you will have a lot of pre-existing code, including the standard library, that would have benefitted from generics, but doesn't because it was written before generics existed. And you will almost certainly have cases where generics don't mesh well with other features. I think that if go was designed from the beginning with generics, then generics probably would have worked better in go (and similarly for java).
za3faran 3y ago
> "Wait for the right implementation" (for generics). Ironically, they still don't have it right. Last time I checked you couldn't have generics on "methods".
- randomdata 3y ago
  There shouldn't be anything in the chosen implementation that prevents generics on methods. The work just hasn't been done yet. There are only so many hours in the day. Feel free to jump in if you have some to spare. A wrong implementation would hamstring making such improvements in the future. It is possible that will still happen in some unforeseen way anyway, but the earlier proposals visibly exhibited problems from the get-go. They were clearly wrong. So far, this one does look right.

zozbot234 3y ago

Wrt. generics they followed in Java's footsteps: they asked the PLT community to come up with a reasonably elegant model that would mesh well with the rest of the language, and then largely stuck to that.

erik_seaberg 3y ago
It took years to root out and torch flawed APIs from the JVM ecosystem. After that example, it’s hard to defend neglecting the problem again and launching with no solution.
- zdragnar 3y ago
  No language launches perfectly. If the cost of adding generics later is "existing code still works, and now this can work too" versus "the old version of genetics is flawed, burn everything down and use this version instead" or "generics didn't work out the way we wanted, use this new thing that's totally-not-generics-wink-wink"... Well, I'd say waiting is the right call. You're already used to adding three extra lines of boilerplate after every single line of code for error handling, living without generics wasn't that hard. Hell, I recall half the go community was convinced they weren't needed at all by the time they came around.
  - masklinn 3y ago
    > No language launches perfectly. There's a gulf between "not launching perfectly" and launching with obvious, blatant deficiencies. Go did the latter. Generics were always going to have to be implemented eventually, at least two languages in basically the space Go was targeting had had to bite that bullet in the decade before it was published. Support for third-party external dependencies only made that more dire. Instead of doing the work up-front and launching with generics, they decided to launch with ad-hoc generic builtins and "lalala can't hear you" for a decade, then finally implement half-assed generics.
  - kaba0 3y ago
    Languages are not created in a vacuum, or at least sane ones are not. Go failed to take into account the last 50 years of PL design, and it shows in its ridiculous number of shortcomings.
- philosopher1234 3y ago
  The idea that it would be better if go waited an additional year or two to launch with generics is laughable. That extra year probably makes the difference for the languages success.
  - erik_seaberg 3y ago
    If you mean that another language with more planning might have caught on, I think that would have been a better outcome.
    - philosopher1234 3y ago
      Why would a better planned language win and not one that rushed and beat go to the finish?
      - valenterry 3y ago
        That's not what he said. He said IF that WOULD have happened, it would have been better for everyone except for the Go designers.
        philosopher1234 3y ago
        My point is that if you delayed the release of Go, there’s no reason to believe you end up with a better world. So his argument is bunk.
        valenterry 3y ago
        Why not? I think his reasoning makes sense. Unless you mean that having a language with better design (but being released later) is not an improvement.
        philosopher1234 3y ago
        My argument is that timing is very important to adoption. Unix is not the best OS to have been designed by far, but it was the first free one. If go had been delayed, something else may have filled the slot, and there’s no reason to believe it would have been a better something else. I.e when Go did release 2 years later, but with generics, it’d be too late, and no one would care.
thayne 3y ago
I think that generics is really difficult to do well when added to a language later. At the very least you will have a lot of pre-existing code, including the standard library, that would have benefitted from generics, but doesn't because it was written before generics existed. And you will almost certainly have cases where generics don't mesh well with other features. I think that if go was designed from the beginning with generics, then generics probably would have worked better in go (and similarly for java).

za3faran 3y ago

> "Wait for the right implementation" (for generics). Ironically, they still don't have it right. Last time I checked you couldn't have generics on "methods".

randomdata 3y ago
There shouldn't be anything in the chosen implementation that prevents generics on methods. The work just hasn't been done yet. There are only so many hours in the day. Feel free to jump in if you have some to spare. A wrong implementation would hamstring making such improvements in the future. It is possible that will still happen in some unforeseen way anyway, but the earlier proposals visibly exhibited problems from the get-go. They were clearly wrong. So far, this one does look right.