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
> 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
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 - note that Russ was just ignoring the literal package management committee set up to look at this - https://twitter.com/sdboyer/status/1034893509394882562
Look at 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.