5 ms·

It's a dangerous type of articles that deliberately turns community against Go team, based on misunderstanding or plain false accusations. Go team said many ti

by divan 7y ago

It's a dangerous type of articles that deliberately turns community against Go team, based on misunderstanding or plain false accusations. Go team said many times that generics are technical issue, not a political one. (see [1] by rsc (Russ Cox from Go team)) There are also stories like experience report of Cloudflare outage due to the lack of monotonic clock support in Go that led to introducing one. [2] The way how Go team handles potentially tectonic changes in language is also exemplary – very well communicated ideas, means to provide feedback, and clear explanation of how process works. [3] Plus, many people in Go community do not want generics in Go (at least, in a way they're implemented in other languages). Their opinion also matters. [1] https://news.ycombinator.com/item?id=9622417 https://news.ycombinator.com/item?id=9622417 [2] https://blog.golang.org/toward-go2 https://blog.golang.org/toward-go2 [3] https://go.googlesource.com/proposal/+/master/design/go2draft.md https://go.googlesource.com/proposal/+/master/design/go2draf...

brown9-2 7y ago
In my opinion the monotonic clock example cuts against this argument - originally the core team was extremely dismissive of the idea, even though it had been shown to cause pain for a lot of people: https://github.com/golang/go/issues/12914#issuecomment-150754067 https://github.com/golang/go/issues/12914#issuecomment-15075...
- Aissen 7y ago
  But the implementation that rsc came up with was much better than everything proposed by the community (no API change).
  - pas 7y ago
    Crisis is always a great opportunity as the pressure motivates people to ship, while also to do their best, to really consider any and all options, everything that might work. Sometimes, of course, this does not work out for the best.
- divan 7y ago
  It's a great example, as it shows the complexity of the discussed topic and attempt to justify any changes to the language/stdlib. In the above-mentioned comment rsc replies to another Googler, not to "community". So we have a) Google having problems with lack of monotonic clock in Go b) Go team reluctant to break API and break promise of compatibility without really serious reason c) community feedback in form of well written experience report, explaining how serious the issue is for the community d) immediate reaction and efforts to find a solution (without breaking API) Even though team was dismissive of the idea, feedback from the community made them to change their minds.
  - apta 7y ago
    Or, you can view this from another angle, that the golang authors yet again disregarded previous established work in the industry for the sake of avoiding hard work in the language and the compiler. It's no wonder the time package in golang is garbage compared to established offerings in mature languages like Java and C#.
    - Retra 7y ago
      It's no wonder that a new language is lacking the maturity and features of an old language. Of course you can attribute it to 'avoiding the hard work', but that's the same reason you don't live in a crystal castle. A more salient criticism would highlight what they have been spending their time on, rather than pointing out that they haven't spent much time on something.
      - apta 7y ago
        The logical thing to do is to build on what other languages did, and use established practices. Comparing what Rust did to golang when it comes to generics for example is enough to show the mentality of the golang authors refusing to look at established work.
        divan 7y ago
        I disagree, as I remember a lot of talks and articles from Go team members where they discuss in detail established work in other languages – on GC, on language evolution, on generics and so on – and deliberately learn from them to avoid same mistakes.
computerex 7y ago
The article barely even talks about generics, though (and takes a favorable position towards the Go team). What are you on about? Did you read the same article I did? https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGoo... The author's primary complaint is the way Go modules were handled, namely that one member of the Go core team overrode the entire community.
- divan 7y ago
  > barely even talks about generics Yet uses it as an opening line to build the whole argument on.
  - computerex 7y ago
    He doesn't build the whole argument on it. Generics just happens to be one of the most polarizing, most talked about subjects in the Go community. It's no surprise the author alludes to it. In his own words: > PS: I like Go and have for a fair while now, and I'm basically okay with how the language has been evolving and how the Go core team has managed it. I certainly think it's a good idea to take things like generics slowly. But at the same time, how things developed around Go modules has left a bad taste in my mouth and I now can't imagine becoming a Go contributor myself, even for small trivial changes (to put it one way, I have no interest in knowing that I'm always going to be a second class citizen). I'll file bug reports, but that's it. The whole situation leaves me with ambiguous feelings, so I usually ignore it completely.

by divan 7y ago

brown9-2 7y ago

In my opinion the monotonic clock example cuts against this argument - originally the core team was extremely dismissive of the idea, even though it had been shown to cause pain for a lot of people: https://github.com/golang/go/issues/12914#issuecomment-150754067 https://github.com/golang/go/issues/12914#issuecomment-15075...

Aissen 7y ago
But the implementation that rsc came up with was much better than everything proposed by the community (no API change).
- pas 7y ago
  Crisis is always a great opportunity as the pressure motivates people to ship, while also to do their best, to really consider any and all options, everything that might work. Sometimes, of course, this does not work out for the best.
divan 7y ago
It's a great example, as it shows the complexity of the discussed topic and attempt to justify any changes to the language/stdlib. In the above-mentioned comment rsc replies to another Googler, not to "community". So we have a) Google having problems with lack of monotonic clock in Go b) Go team reluctant to break API and break promise of compatibility without really serious reason c) community feedback in form of well written experience report, explaining how serious the issue is for the community d) immediate reaction and efforts to find a solution (without breaking API) Even though team was dismissive of the idea, feedback from the community made them to change their minds.
- apta 7y ago
  Or, you can view this from another angle, that the golang authors yet again disregarded previous established work in the industry for the sake of avoiding hard work in the language and the compiler. It's no wonder the time package in golang is garbage compared to established offerings in mature languages like Java and C#.
  - Retra 7y ago
    It's no wonder that a new language is lacking the maturity and features of an old language. Of course you can attribute it to 'avoiding the hard work', but that's the same reason you don't live in a crystal castle. A more salient criticism would highlight what they have been spending their time on, rather than pointing out that they haven't spent much time on something.
    - apta 7y ago
      The logical thing to do is to build on what other languages did, and use established practices. Comparing what Rust did to golang when it comes to generics for example is enough to show the mentality of the golang authors refusing to look at established work.
      - divan 7y ago
        I disagree, as I remember a lot of talks and articles from Go team members where they discuss in detail established work in other languages – on GC, on language evolution, on generics and so on – and deliberately learn from them to avoid same mistakes.

computerex 7y ago

The article barely even talks about generics, though (and takes a favorable position towards the Go team). What are you on about? Did you read the same article I did? https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGooglesLanguage https://utcc.utoronto.ca/~cks/space/blog/programming/GoIsGoo... The author's primary complaint is the way Go modules were handled, namely that one member of the Go core team overrode the entire community.

divan 7y ago
> barely even talks about generics Yet uses it as an opening line to build the whole argument on.
- computerex 7y ago
  He doesn't build the whole argument on it. Generics just happens to be one of the most polarizing, most talked about subjects in the Go community. It's no surprise the author alludes to it. In his own words: > PS: I like Go and have for a fair while now, and I'm basically okay with how the language has been evolving and how the Go core team has managed it. I certainly think it's a good idea to take things like generics slowly. But at the same time, how things developed around Go modules has left a bad taste in my mouth and I now can't imagine becoming a Go contributor myself, even for small trivial changes (to put it one way, I have no interest in knowing that I'm always going to be a second class citizen). I'll file bug reports, but that's it. The whole situation leaves me with ambiguous feelings, so I usually ignore it completely.