> This is clearly detrimental to external projects such as Go packaging Indeed. Google's monorepo means the largest cohort of Go programmers in the world are

> This is clearly detrimental to external projects such as Go packaging Indeed. Google's monorepo means the largest cohort of Go programmers in the world are mostly indifferent to composing packages in the usual (cpan/maven/composer/npm/nuget/cargo/swift/pip/rubygems/bower/etc) manner. Non-Google Go programmers have been left to schlep around with marginal solutions for years, although in the last few months we begin to see progress here[1]. This was the #1 discouragement I experienced when experimenting with Go. Google's monorepo may be wonderful from Google's perspective but I don't think it's been a win for Go. * yes I know some of these are also build systems and provide many other capabilities, some of which are arguably detrimental. Versioned, packaged, signed dependencies and thus repeatable build artifacts is the point. [1] https://github.com/golang/go/issues/24301 https://github.com/golang/go/issues/24301