4 ms·

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 sh

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.
        apta 7y ago
        It's not a matter of agreement or disagreement. It's facts. Another user on here put it well: https://news.ycombinator.com/item?id=19979613 https://news.ycombinator.com/item?id=19979613
        divan 7y ago
        The fact is Go team learns from other implementations and it's clear from talks and articles. Another fact is that you're accusing them in having the "mindset of refusing to look at established work". Those two facts don't get along together, that's why I disagree.
        7y ago

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.
      - apta 7y ago
        It's not a matter of agreement or disagreement. It's facts. Another user on here put it well: https://news.ycombinator.com/item?id=19979613 https://news.ycombinator.com/item?id=19979613
        divan 7y ago
        The fact is Go team learns from other implementations and it's clear from talks and articles. Another fact is that you're accusing them in having the "mindset of refusing to look at established work". Those two facts don't get along together, that's why I disagree.
        7y ago