4 ms·

Nothing core though, and the godep thing is disputed by those involved - https://twitter.com/sdboyer/status/1034893100450291713 https://twitter.com/sdboyer/stat

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...
- barnacled 6y ago
  All very reasonable, thank you for taking the time to reply! I think it's first important to note that Russ Cox himself admitted that the whole go dep vs modules thing was poorly handled which really does back up my point of view - https://twitter.com/_rsc/status/1022588240501661696 https://twitter.com/_rsc/status/1022588240501661696 > looks like from that thread that the Go team was never on board with certain technical aspects of how dep was implemented. Note that the package management committee were _regularly_ meeting with Russ about this, e.g. https://twitter.com/_rsc/status/1022588240501661696 https://twitter.com/_rsc/status/1022588240501661696 They were well apprised of what was going on, I am not sure there was much of an end-run at all - https://twitter.com/sdboyer/status/1034893126320771072 https://twitter.com/sdboyer/status/1034893126320771072 - note that Russ was just ignoring the literal package management committee set up to look at this - https://twitter.com/sdboyer/status/1034893509394882562 https://twitter.com/sdboyer/status/1034893509394882562 Look at https://twitter.com/sdboyer/status/1034894397261979649 https://twitter.com/sdboyer/status/1034894397261979649: 'To the extent i was defensive, it was primarily from having to field yet another greenfield idea, after months of silence.' If the technical lead literally ignores the package management committee set up to look at package management and goes off and does his own thing - what does that say about community engagement? This is about the largest [officially sanctioned] community engagement on something semi-core to the language and look at what happened. >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 don't even think this is relevant - it's perfectly fine for people to disagree and for Russ to say no, that's his role as BDFL, but to ignore and not engage at all? The committee could have been pushed in the direction Russ preferred rather than going off and doing his own thing. Or perhaps they could have been told 'sorry we have decided to go in another direction so we don't need you any more'. >They've made almost no changes to the language so far I was involved in contributing to the compiler in 2011 back when many changes were made both in terms of language, compiler and standard library. When I worked on it the compiler was written in C (!) So even when that was not true, the attitude was the same (which is what put me off continuing to be involved in the project). >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. It's good they listen to community feedback but that's not the same as accepting fundamental or even not that fundamental language or standard library changes. Other language projects like python for example, have retained a strict attitude to development but had actual community support through small and big changes to both language and library. It is clearly possible to both maintain a strict philosophy AND accept serious patches from the community. Again I really have no problem with how they approach things but I do have a problem with the dishonesty about that. They should not set up a package management committee then ignore them, or say you'll accept proposals but then only accept core google employee ones. I think sometimes people will argue back and forth on details but miss the bigger picture - perhaps that's what we're doing here. The culture of a project (not relevant here but also applicable to companies) always percolates down from the top - ruby, python, haskell, for a non language example of course the linux kernel - each have their own culture, attitude and approach that is clearly informed by the founders/core maintainers. The same is clearly true of go. I look forward to being proven wrong and when a significant standard library or language change occurs (and v2 is where that would have happened clearly) from the community but I don't think it's going to happen. And again maybe it shouldn't, maybe go is better off run the way it is, but they should be honest - you can't have it both ways, it's one or the other. >an enormous amount of work that an expert would have to put in for free Finally - I dislike the gatekeeping idea of an 'expert', especially for a language like go which is so explicitly anti-academic. Surely what should matter is how well argued a proposal is? Unless you mean a go expert but there are plenty in the community who are. As for enormous amount of work being put in for free, I think many would have loved to have the kudos of being the person who invented generics for go and would have happily done so. The history of open source is replete with people who have done enormous amounts of work for free - gcc for example. But you could also imagine an employee of some other company being paid to do it, as happens with the linux kernel very often. Again, I really doubt that an 'expert' (however we want to define it) hired by anybody other than google or even as a hobby submitting the exact same proposal would have got the acceptance Ian and Robert have received. The community will be used as a sounding board no doubt to cover any edge cases they've not thought about but again that's not the same as somebody being able to _submit_ changes like this. In any case I don't mean to be hostile here - I wish golang every success and it's well deserved, the core team are extremely talented and I hope they go on to greater and greater success.

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...

barnacled 6y ago
All very reasonable, thank you for taking the time to reply! I think it's first important to note that Russ Cox himself admitted that the whole go dep vs modules thing was poorly handled which really does back up my point of view - https://twitter.com/_rsc/status/1022588240501661696 https://twitter.com/_rsc/status/1022588240501661696 > looks like from that thread that the Go team was never on board with certain technical aspects of how dep was implemented. Note that the package management committee were _regularly_ meeting with Russ about this, e.g. https://twitter.com/_rsc/status/1022588240501661696 https://twitter.com/_rsc/status/1022588240501661696 They were well apprised of what was going on, I am not sure there was much of an end-run at all - https://twitter.com/sdboyer/status/1034893126320771072 https://twitter.com/sdboyer/status/1034893126320771072 - note that Russ was just ignoring the literal package management committee set up to look at this - https://twitter.com/sdboyer/status/1034893509394882562 https://twitter.com/sdboyer/status/1034893509394882562 Look at https://twitter.com/sdboyer/status/1034894397261979649 https://twitter.com/sdboyer/status/1034894397261979649: 'To the extent i was defensive, it was primarily from having to field yet another greenfield idea, after months of silence.' If the technical lead literally ignores the package management committee set up to look at package management and goes off and does his own thing - what does that say about community engagement? This is about the largest [officially sanctioned] community engagement on something semi-core to the language and look at what happened. >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 don't even think this is relevant - it's perfectly fine for people to disagree and for Russ to say no, that's his role as BDFL, but to ignore and not engage at all? The committee could have been pushed in the direction Russ preferred rather than going off and doing his own thing. Or perhaps they could have been told 'sorry we have decided to go in another direction so we don't need you any more'. >They've made almost no changes to the language so far I was involved in contributing to the compiler in 2011 back when many changes were made both in terms of language, compiler and standard library. When I worked on it the compiler was written in C (!) So even when that was not true, the attitude was the same (which is what put me off continuing to be involved in the project). >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. It's good they listen to community feedback but that's not the same as accepting fundamental or even not that fundamental language or standard library changes. Other language projects like python for example, have retained a strict attitude to development but had actual community support through small and big changes to both language and library. It is clearly possible to both maintain a strict philosophy AND accept serious patches from the community. Again I really have no problem with how they approach things but I do have a problem with the dishonesty about that. They should not set up a package management committee then ignore them, or say you'll accept proposals but then only accept core google employee ones. I think sometimes people will argue back and forth on details but miss the bigger picture - perhaps that's what we're doing here. The culture of a project (not relevant here but also applicable to companies) always percolates down from the top - ruby, python, haskell, for a non language example of course the linux kernel - each have their own culture, attitude and approach that is clearly informed by the founders/core maintainers. The same is clearly true of go. I look forward to being proven wrong and when a significant standard library or language change occurs (and v2 is where that would have happened clearly) from the community but I don't think it's going to happen. And again maybe it shouldn't, maybe go is better off run the way it is, but they should be honest - you can't have it both ways, it's one or the other. >an enormous amount of work that an expert would have to put in for free Finally - I dislike the gatekeeping idea of an 'expert', especially for a language like go which is so explicitly anti-academic. Surely what should matter is how well argued a proposal is? Unless you mean a go expert but there are plenty in the community who are. As for enormous amount of work being put in for free, I think many would have loved to have the kudos of being the person who invented generics for go and would have happily done so. The history of open source is replete with people who have done enormous amounts of work for free - gcc for example. But you could also imagine an employee of some other company being paid to do it, as happens with the linux kernel very often. Again, I really doubt that an 'expert' (however we want to define it) hired by anybody other than google or even as a hobby submitting the exact same proposal would have got the acceptance Ian and Robert have received. The community will be used as a sounding board no doubt to cover any edge cases they've not thought about but again that's not the same as somebody being able to _submit_ changes like this. In any case I don't mean to be hostile here - I wish golang every success and it's well deserved, the core team are extremely talented and I hope they go on to greater and greater success.