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

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.