4 ms·

> Go core would go on ignoring community progress Any examples? Perhaps you mean either Generics or the module system (the two elephants in the rather large an

by why-el 7y ago

> Go core would go on ignoring community progress Any examples? Perhaps you mean either Generics or the module system (the two elephants in the rather large and accommodating room)? I read almost all proposals for Generics, and, perhaps to my inexperienced eyes, the problem seems hard. The ramifications on the language design are not trivial, and the benefits, again, from my quite limited world view, are not so easy to quantify, otherwise how can one justify the extreme productivity spawned by the language? In the cloud business no less. I have almost no stake in this, I don't even use the language professionally, but I find the supposed criticism a bit over the top. I'd wager that an example implementation of Generics that fits nicely with the language and works for a big and healthy code base would absolutely not go unnoticed by Russ and the other core members, but we have to accept that it is not easy.

pjmlp 7y ago
Yet other language communities managed to do it since the mid-70's.
- chewxy 7y ago
  I put it to you that most other language communities do not deliberate as much on generics. Consider the document that Ian Lance Taylor put out: https://github.com/golang/proposal/blob/master/design/15292/2013-12-type-params.md https://github.com/golang/proposal/blob/master/design/15292/... More research here: https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/view#heading=h.vuko0u3txoew https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX... I have also given it a bit of thinking on the tradeoffs: https://blog.chewxy.com/2017/09/11/tensor-refactor/#some-thoughts-on-generics-in-go https://blog.chewxy.com/2017/09/11/tensor-refactor/#some-tho... The Go community may be stuck on an analysis paralysis mode, but it's much better than ad hoc implementation that will stay forever.
  - coldtea 7y ago
    There's a proverb in these here parts that goes like "He who doesn't want to kneed dough, keeps sifting flour". Perhaps a modern dev-friendly version would be, "He who doesn't want to code, keeps configuring their text editor". That seems to be the case with Generics and the endless "documents" and "analysis" in Go. If you don't particularly want to do something, you keep analyzing different ways of doing it...
    - chewxy 7y ago
      Most of these "analyses" especially from Ian has backing code changes. This for example, is my experiment with trying to give Go a backing calculus that supports generics https://asciinema.org/a/166748 https://asciinema.org/a/166748 The runtime changes yielded over 20k lines of changes - basically about 1/4th of the Go runtime has to change. Not to mention a large amount of semantics changed too - essentially a different language
      - coldtea 7y ago
        >The runtime changes yielded over 20k lines of changes - basically about 1/4th of the Go runtime has to change. Not to mention a large amount of semantics changed too Well, isn't it a major typesystem change? Makes sense for it to apply to a big part of the runtime and semantics.
    - philwelch 7y ago
      There’s another proverb that I think applies better: “measure twice, cut once”.
      - zimpenfish 7y ago
        Having buggered up a half-lap joint the other month even though I measured things several times, I'd like to propose a change to this proverb. "measure twice, think twice, cut once" (or even "think twice, cut once" if you want to generalise it to other spheres)
      - gdy 7y ago
        In the Russian version of this proverb you'd need to measure seven times)
  - pjmlp 7y ago
    You mean the usual documents that get thrown into generics discussions, where he keeps talking about C++ and Java, while ignoring all other programming languages designed since CLU and ML in the 70's? "In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier." https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...
    - grumpydba 7y ago
      This has been acknowledged and addressed. What is your proposal?
      - pjmlp 7y ago
        I don't know, that they actually implement them, instead of doing proposal after proposal?!? Even the ideas that eventually die on the Web, C++, Java and .NET happen to have preview implementations available to try out at one point, instead of dead paper.
        grumpydba 7y ago
        I don't think it is efficient to implement a dozen of ways to handle generics. People who need generics will use code generation until the issue is addressed, I don't really see the need to rush. Attention to details is something I like about go.
        pjmlp 7y ago
        Just like C++ MS-DOS compilers used to do before ANSI/ISO started to work on templates, about 30 years ago, talk about progress.
    - shaklee3 7y ago
      C++ has concepts now. What's the excuse?
- unionpivo 7y ago
  There are plenty of people, myself included, who would prefer no generics than bad generics. The big reason for me to use GO is it's simplicity. I can pick any programmer, give him a few days to a week, and he will be productive. Python used to be somewhat simple (never really that simple) with goal of having 1 "obvious" way of doing anything. I think GO is better at that, than python ever was, and I think that is one of the bigger reasons for it's success.
  - pjmlp 7y ago
    Bad generics is what happens to any programming language not designed with them from the start, specially when one ignores 30 years of experience.
jcora 7y ago
Except that they admitted that they didn't really look beyond C++ and Java implementations. Their aversions to modern language design and type theory are pretty obvious. Also, lots of code can be written in a bad language. And a language can be practical without being good from a language design perspective, the difference is in the richness of the ecosystem, the stdlib, and 'meeting programmers where they are'.
- erik_seaberg 7y ago
  > lots of code can be written in a bad language That's actually the problem. Bad languages require reading and writing too much repetitive code, just to replace missing abstractions.

by why-el 7y ago

pjmlp 7y ago

Yet other language communities managed to do it since the mid-70's.

chewxy 7y ago
I put it to you that most other language communities do not deliberate as much on generics. Consider the document that Ian Lance Taylor put out: https://github.com/golang/proposal/blob/master/design/15292/2013-12-type-params.md https://github.com/golang/proposal/blob/master/design/15292/... More research here: https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/view#heading=h.vuko0u3txoew https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX... I have also given it a bit of thinking on the tradeoffs: https://blog.chewxy.com/2017/09/11/tensor-refactor/#some-thoughts-on-generics-in-go https://blog.chewxy.com/2017/09/11/tensor-refactor/#some-tho... The Go community may be stuck on an analysis paralysis mode, but it's much better than ad hoc implementation that will stay forever.
- coldtea 7y ago
  There's a proverb in these here parts that goes like "He who doesn't want to kneed dough, keeps sifting flour". Perhaps a modern dev-friendly version would be, "He who doesn't want to code, keeps configuring their text editor". That seems to be the case with Generics and the endless "documents" and "analysis" in Go. If you don't particularly want to do something, you keep analyzing different ways of doing it...
  - chewxy 7y ago
    Most of these "analyses" especially from Ian has backing code changes. This for example, is my experiment with trying to give Go a backing calculus that supports generics https://asciinema.org/a/166748 https://asciinema.org/a/166748 The runtime changes yielded over 20k lines of changes - basically about 1/4th of the Go runtime has to change. Not to mention a large amount of semantics changed too - essentially a different language
    - coldtea 7y ago
      >The runtime changes yielded over 20k lines of changes - basically about 1/4th of the Go runtime has to change. Not to mention a large amount of semantics changed too Well, isn't it a major typesystem change? Makes sense for it to apply to a big part of the runtime and semantics.
  - philwelch 7y ago
    There’s another proverb that I think applies better: “measure twice, cut once”.
    - zimpenfish 7y ago
      Having buggered up a half-lap joint the other month even though I measured things several times, I'd like to propose a change to this proverb. "measure twice, think twice, cut once" (or even "think twice, cut once" if you want to generalise it to other spheres)
    - gdy 7y ago
      In the Russian version of this proverb you'd need to measure seven times)
- pjmlp 7y ago
  You mean the usual documents that get thrown into generics discussions, where he keeps talking about C++ and Java, while ignoring all other programming languages designed since CLU and ML in the 70's? "In retrospect, we were biased too much by experience with C++ without concepts and Java generics. We would have been well-served to spend more time with CLU and C++ concepts earlier." https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf...
  - grumpydba 7y ago
    This has been acknowledged and addressed. What is your proposal?
    - pjmlp 7y ago
      I don't know, that they actually implement them, instead of doing proposal after proposal?!? Even the ideas that eventually die on the Web, C++, Java and .NET happen to have preview implementations available to try out at one point, instead of dead paper.
      - grumpydba 7y ago
        I don't think it is efficient to implement a dozen of ways to handle generics. People who need generics will use code generation until the issue is addressed, I don't really see the need to rush. Attention to details is something I like about go.
        pjmlp 7y ago
        Just like C++ MS-DOS compilers used to do before ANSI/ISO started to work on templates, about 30 years ago, talk about progress.
  - shaklee3 7y ago
    C++ has concepts now. What's the excuse?
unionpivo 7y ago
There are plenty of people, myself included, who would prefer no generics than bad generics. The big reason for me to use GO is it's simplicity. I can pick any programmer, give him a few days to a week, and he will be productive. Python used to be somewhat simple (never really that simple) with goal of having 1 "obvious" way of doing anything. I think GO is better at that, than python ever was, and I think that is one of the bigger reasons for it's success.
- pjmlp 7y ago
  Bad generics is what happens to any programming language not designed with them from the start, specially when one ignores 30 years of experience.

jcora 7y ago

Except that they admitted that they didn't really look beyond C++ and Java implementations. Their aversions to modern language design and type theory are pretty obvious. Also, lots of code can be written in a bad language. And a language can be practical without being good from a language design perspective, the difference is in the richness of the ecosystem, the stdlib, and 'meeting programmers where they are'.

erik_seaberg 7y ago
> lots of code can be written in a bad language That's actually the problem. Bad languages require reading and writing too much repetitive code, just to replace missing abstractions.