> I don't understand why Go is so insistent that dependency management is something for the community to solve, and not something that should be provided by Go itself.
They don't want to try solving a problem they don't really have. As RSC says:
> the community understands and encounters these problems more than we on the Go team at Google do.
I find it worrying that Go is seemingly entirely stewarded by a company whose technical workflow is so different, to the extent that it curtails technical decisions. It's designing for the lowest common denominator in an equation that emphasizes Google.
Even if your company doesn't need or want Bundler/Cargo-style dependency management doesn't mean that you are intellectually unfit to design out a good solution together with the community. Dogfooding is great and all, but it's actually possible to design technical solutions that you won't personally use.
I get really disappointed when reading such responses. Even when large companies admin they don't know everything and want to see and listen to the rest of the world, its not good enough.
> I find it worrying that Go is seemingly entirely stewarded by a company whose technical workflow is so different, to the extent that it curtails technical decisions.
Having worked at a few such, this is utterly unsurprising. Large development organizations, ala Google, Amazon, etc. are utterly unlike anything on "the outside". This happens slowly over time and is a combination of many factors: centralization of infrastructure, sheer scale (the developer tools teams in many of these shops are often bigger than many other entire software companies), the ability to make cross-cutting decisions for the organization in ways that aren't appropriate for a decentralied external community, etc.
Given all that, I give huge props to the Go team for this kind of self-restraint. It's an enourmously painful decision for the community, but absolutely the right one if you aren't actually feeling the pain. I've seen too many communities suffer because of bad decisions and/or churn as the packaging system breaks and is forced to evolve.
> I find it worrying that Go is seemingly entirely stewarded by a company whose technical workflow is so different, to the extent that it curtails technical decisions. It's designing for the lowest common denominator in an equation that emphasizes Google.
There are thousands of programming languages out there, yet Go has quite a bit of traction. They haven't forced anyone to use it, so there must be some reason for that. Maybe Go is successful because it was made with Google's technical workflow in mind.
> Maybe Go is successful because it was made with Google's technical workflow in mind
Sure, but Dart has a fully featured package manager, are you saying Dart was designed at Google without Google's technical workflow in mind? It's silly.
> There are thousands of programming languages out there,
More like hundreds of viable programming languages, not thousands. Anybody can code a lisp in his bedroom,doesn't mean it's production ready.
> They haven't forced anyone to use it
It's a childish and arrogant statement. Just like the "You don't need that in Go"TM. Opening source something was a political decision, but if you're saying Go doesn't need a community then by all means, state it clearly.
> They don't want to try solving a problem they don't really have.
yet Dart has an official package manager ,which is called pub.
So the Go team don't want to solve this problem because they don't have this problem , but the Dart team wants to solve this problem even though they don't have this problem? Do you know what is the name for that? it's not technicality is is called POLITICS.
It's not a political thing. The Go team and the Dart team have different design philosophies. If this were not the case, then they wouldn't be making two different languages.
At google, the entire codebase is basically one big repo. Everything uses the newest version of everything. There is essentially no dependency management because there are no dependencies.
They don't want to try solving a problem they don't really have. As RSC says:
> the community understands and encounters these problems more than we on the Go team at Google do.