5 ms·

I think you're strawmanning/misunderstanding me a bit to say 'just not going to take any contribution come their way'. I never suggested they ought to, the poin

I think you're strawmanning/misunderstanding me a bit to say 'just not going to take any contribution come their way'. I never suggested they ought to, the point is they seem NEVER to take any significant contribution from outside the Google team, like at all. >For people outside if their thinking aligned with core team they will feel welcome and others will feel unwelcome due to high handedness of core team. No, whether you align or not major contributions are not accepted. See the godep vs. go modules debacle for example. And again, that's all fine with me, and I can see why they'd operate that way, but they claim not to which is my major beef (and allow people to work very hard at contributing without realising it's not going to get them anywhere).

throwaway34241 6y ago
I think there’s been largish contributions to the compiler (webassembly backend etc) done by external people. For language changes, don’t they have a formal proposal process where someone submits a spec and the the team (and community) provides feedback before changes are accepted? If you accept that’s reasonable it explains some of how things have happened with dep and generics. If I remember right dep was becoming a de-facto standard without ever submitting to the proposal process where the Go team could address their technical differences. Obviously there was a messaging failure here and they could have emphasized that it was not formally accepted, but it’s tough to tell people not to use a major improvement to the status quo when there is no alternative to point to and hasn’t been for years. For language changes so far there’s been almost zero changes approved, by anyone, including the core team, so it’s hard to make a comparison. But if you look at the current generics proposal it’s an enormous amount of work to completely specify. As far as I know, there have been zero actual proposals by the community and several by the core team (most of which were rejected). I think the community sentiment has been more that we should have generics, or “wouldn’t this feature be useful” on the issue tracker without fully fleshing it out, not actually making formal proposals and getting shot down.
- barnacled 6y ago
  Nothing core though, and the godep thing is disputed by those involved - https://twitter.com/sdboyer/status/1034893100450291713 https://twitter.com/sdboyer/status/1034893100450291713 - more or less they got passed over after spending a bunch of time on it. It's complicated and there was miscommunication but it forms part of the pattern. I'm pretty sure there's been several different proposals for generics. And I seriously doubt anybody external to the go team submitting even an identical draft would be listened to. Lots of discussion documented at https://github.com/golang/go/wiki/ExperienceReports#generics https://github.com/golang/go/wiki/ExperienceReports#generics e.g. https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit# https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX... Even the tracker issue at https://github.com/golang/go/issues/15292 https://github.com/golang/go/issues/15292 states 'he intent is not to add generics to Go at this time, but rather to show people what a complete proposal would look like' - does that sound like they're open to an external person proposing it? I saw it even on a small scale back in 2011, back then I knew the generics thing would be solely implemented by the google guys. There is clearly a 'not invented here syndrome' going on which is entirely understandable actually for a programming language, I just wish there was more transparency on it. The second a core language change actually involves a person external to google or the team drop the concept that that could happen I'll withdraw my criticism.
  - throwaway34241 6y ago
    > It's complicated and there was miscommunication but it forms part of the pattern. It looks like from that thread that the Go team was never on board with certain technical aspects of how dep was implemented. Obviously there are trade offs so it's hard to determine what answer is "right", but opposing a design for technical reasons is still pretty different than pure "not invented here syndrome". The dep author in that thread says part of the reason he did not make a proposal was he was worried "what negative community consequences (wasted work/goodwill) a misfire proposal might have." But since dep was becoming a de-facto standard, skipping the proposal process was basically doing an end-run against the technical decisions of the Go team (and others in the community not already aboard the dep train). I have to admit I'm a bit biased here, I use Go and Go modules, followed closely the discussions at the time, and strongly prefer the trade offs made by the (now official) Go package manager over those made by dep. I can understand how people with different priorities (or who dislike Go in general) might feel differently, but I think it's a bit unfair to call rejecting something over real technical trade offs "not invented here" thinking. > I'm pretty sure there's been several different proposals for generics I don't know of any? By formal proposal I think they mean complete specification of how it would work with the existing features, not just the start of an idea, because of course you need that to actually add it to the language. I think few people expected someone external to the Go team would do it, but I think that's more because it's an enormous amount of work that an expert would have to put in for free. In the end I believe even the Go team ended up asking for help from academic specialists to work out the details. [1] > The second a core language change actually involves a person external to google or the team drop the concept that that could happen I'll withdraw my criticism They've made almost no changes to the language so far so obviously the evidence is still out on the former case, but for the latter I believe Russ Cox's check/handle proposal [2] and Robert Griesemer's try proposal [3] (both core team members) were rejected after community feedback. [1] https://arxiv.org/pdf/2005.11710.pdf https://arxiv.org/pdf/2005.11710.pdf [2] https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf... [3] https://go.googlesource.com/proposal/+/master/design/32437-try-builtin.md https://go.googlesource.com/proposal/+/master/design/32437-t...

throwaway34241 6y ago

I think there’s been largish contributions to the compiler (webassembly backend etc) done by external people. For language changes, don’t they have a formal proposal process where someone submits a spec and the the team (and community) provides feedback before changes are accepted? If you accept that’s reasonable it explains some of how things have happened with dep and generics. If I remember right dep was becoming a de-facto standard without ever submitting to the proposal process where the Go team could address their technical differences. Obviously there was a messaging failure here and they could have emphasized that it was not formally accepted, but it’s tough to tell people not to use a major improvement to the status quo when there is no alternative to point to and hasn’t been for years. For language changes so far there’s been almost zero changes approved, by anyone, including the core team, so it’s hard to make a comparison. But if you look at the current generics proposal it’s an enormous amount of work to completely specify. As far as I know, there have been zero actual proposals by the community and several by the core team (most of which were rejected). I think the community sentiment has been more that we should have generics, or “wouldn’t this feature be useful” on the issue tracker without fully fleshing it out, not actually making formal proposals and getting shot down.

barnacled 6y ago
Nothing core though, and the godep thing is disputed by those involved - https://twitter.com/sdboyer/status/1034893100450291713 https://twitter.com/sdboyer/status/1034893100450291713 - more or less they got passed over after spending a bunch of time on it. It's complicated and there was miscommunication but it forms part of the pattern. I'm pretty sure there's been several different proposals for generics. And I seriously doubt anybody external to the go team submitting even an identical draft would be listened to. Lots of discussion documented at https://github.com/golang/go/wiki/ExperienceReports#generics https://github.com/golang/go/wiki/ExperienceReports#generics e.g. https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit# https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX... Even the tracker issue at https://github.com/golang/go/issues/15292 https://github.com/golang/go/issues/15292 states 'he intent is not to add generics to Go at this time, but rather to show people what a complete proposal would look like' - does that sound like they're open to an external person proposing it? I saw it even on a small scale back in 2011, back then I knew the generics thing would be solely implemented by the google guys. There is clearly a 'not invented here syndrome' going on which is entirely understandable actually for a programming language, I just wish there was more transparency on it. The second a core language change actually involves a person external to google or the team drop the concept that that could happen I'll withdraw my criticism.
- throwaway34241 6y ago
  > It's complicated and there was miscommunication but it forms part of the pattern. It looks like from that thread that the Go team was never on board with certain technical aspects of how dep was implemented. Obviously there are trade offs so it's hard to determine what answer is "right", but opposing a design for technical reasons is still pretty different than pure "not invented here syndrome". The dep author in that thread says part of the reason he did not make a proposal was he was worried "what negative community consequences (wasted work/goodwill) a misfire proposal might have." But since dep was becoming a de-facto standard, skipping the proposal process was basically doing an end-run against the technical decisions of the Go team (and others in the community not already aboard the dep train). I have to admit I'm a bit biased here, I use Go and Go modules, followed closely the discussions at the time, and strongly prefer the trade offs made by the (now official) Go package manager over those made by dep. I can understand how people with different priorities (or who dislike Go in general) might feel differently, but I think it's a bit unfair to call rejecting something over real technical trade offs "not invented here" thinking. > I'm pretty sure there's been several different proposals for generics I don't know of any? By formal proposal I think they mean complete specification of how it would work with the existing features, not just the start of an idea, because of course you need that to actually add it to the language. I think few people expected someone external to the Go team would do it, but I think that's more because it's an enormous amount of work that an expert would have to put in for free. In the end I believe even the Go team ended up asking for help from academic specialists to work out the details. [1] > The second a core language change actually involves a person external to google or the team drop the concept that that could happen I'll withdraw my criticism They've made almost no changes to the language so far so obviously the evidence is still out on the former case, but for the latter I believe Russ Cox's check/handle proposal [2] and Robert Griesemer's try proposal [3] (both core team members) were rejected after community feedback. [1] https://arxiv.org/pdf/2005.11710.pdf https://arxiv.org/pdf/2005.11710.pdf [2] https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf... [3] https://go.googlesource.com/proposal/+/master/design/32437-try-builtin.md https://go.googlesource.com/proposal/+/master/design/32437-t...