5 ms·

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 modul

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
Oh yeah, I definitely agree that the package management thing was mishandled by the Go team. Maybe they should have pushed back harder against dep even before having a compelling alternative (although that in itself risks community backlash IMO, since dep wasn't that terrible and it was a longstanding problem). Or maybe they should have avoided having a separate committee look at the problem, if they weren't willing to delegate decision-making authority. Or maybe they should have just worked on it themselves much earlier since not having a standard package manager was a big weakness for the Go ecosystem outside Google (who I guess uses a monorepo and doesn't need it)? I feel the dep committee deciding to skip the proposal process was also a mistake though. They might have felt they represented the community, but as a member of the community who didn't support dep I didn't feel represented. People who don't support the general approach are probably not going file github issues in an evolving third party project, but they would have had a chance to discuss it in an actual proposal process where that is expected. > I dislike the gatekeeping idea of an 'expert' > 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 After the Go team (themselves pretty smart) struggled for years to find a design that was acceptable to them, they roped in the Haskell people in that paper who I expect are some of the top type theorists in the world... I don't think it is any insult to the Go community to say that it's a bit big for a volunteer project (and those Haskell people are technically outside Google). It seems like designing a generics system carefully so that it plays well with the rest of the language is probably more work than the entire v1 of the language to begin with. > I think sometimes people will argue back and forth on details but miss the bigger picture - perhaps that's what we're doing here. I guess the big difference in perception is I've viewed the Go team as making decisions mostly based on their technical priorities (minimalism, backwards compatibility, quick compile times, performance, etc) rather than who the ideas came from. I guess this is because whenever I read the technical arguments around one of these issues, the arguments from the Go team most of the time make a lot of sense to me, and when there is a difference of opinion it often comes down to the Go team putting more weight on their already well-known priorities for the project. I mean, Russ Cox must have wrote 50 pages on the nuances of package management when he came out with his dep alternative. And the end result put a lot more emphasis on minimalism and backwards compatibility than dep did. So I guess that made it seem less like merely not-invented-here syndrome. Although if the end result is the same, which is big contributions being mostly done by team members, maybe there's not a lot of practical difference.

throwaway34241 6y ago

Oh yeah, I definitely agree that the package management thing was mishandled by the Go team. Maybe they should have pushed back harder against dep even before having a compelling alternative (although that in itself risks community backlash IMO, since dep wasn't that terrible and it was a longstanding problem). Or maybe they should have avoided having a separate committee look at the problem, if they weren't willing to delegate decision-making authority. Or maybe they should have just worked on it themselves much earlier since not having a standard package manager was a big weakness for the Go ecosystem outside Google (who I guess uses a monorepo and doesn't need it)? I feel the dep committee deciding to skip the proposal process was also a mistake though. They might have felt they represented the community, but as a member of the community who didn't support dep I didn't feel represented. People who don't support the general approach are probably not going file github issues in an evolving third party project, but they would have had a chance to discuss it in an actual proposal process where that is expected. > I dislike the gatekeeping idea of an 'expert' > 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 After the Go team (themselves pretty smart) struggled for years to find a design that was acceptable to them, they roped in the Haskell people in that paper who I expect are some of the top type theorists in the world... I don't think it is any insult to the Go community to say that it's a bit big for a volunteer project (and those Haskell people are technically outside Google). It seems like designing a generics system carefully so that it plays well with the rest of the language is probably more work than the entire v1 of the language to begin with. > I think sometimes people will argue back and forth on details but miss the bigger picture - perhaps that's what we're doing here. I guess the big difference in perception is I've viewed the Go team as making decisions mostly based on their technical priorities (minimalism, backwards compatibility, quick compile times, performance, etc) rather than who the ideas came from. I guess this is because whenever I read the technical arguments around one of these issues, the arguments from the Go team most of the time make a lot of sense to me, and when there is a difference of opinion it often comes down to the Go team putting more weight on their already well-known priorities for the project. I mean, Russ Cox must have wrote 50 pages on the nuances of package management when he came out with his dep alternative. And the end result put a lot more emphasis on minimalism and backwards compatibility than dep did. So I guess that made it seem less like merely not-invented-here syndrome. Although if the end result is the same, which is big contributions being mostly done by team members, maybe there's not a lot of practical difference.