> IMHO such tooling should not be part of the language itself, and be left to the community.

I strongly disagree with this. "All batteries included" is one of Go's strongest points, especially if you look at gofmt, which set a standard for all code out there.

Yeah, I heard this a lot about go. Agree that gofmt is a good call, but it’s not hard to get that one right. I’m seeing more and more of these “included batteries” being deprecated, it’s almost as if standard libraries don’t stay shiny and new forever ;)

Speaking from the perspective of someone with a fair bit of exposure to packaging and shipping software in the Python world, I don't thinking leaving these matters to "the community" results in a satisfactory outcome.

In more practical terms, I expect this tooling is provided and evolved as a first class affair because Google needs it internally to build their golang projects.

See also C and C++.

I disagree on the idea of leaving tooling up to the community. Having one set of tooling that everyone uses is a huge advantage. It really helps projects interoperate with other projects.

"go get" was originally not intended as dependency management, just as a convenient way of getting the latest version of some source code you need from GitHub or other hosters. Ok, when it gets that source code, it will also get its dependencies, but I don't think you can really call that dependency management? Later, it was updated to "play nice" with the "modules"-based dependency management, but that was not the original intention behind it.

But I still prefer to have the occasional churn when "the official way of doing things" changes to having x competing tools doing the same thing, which has the potential of generating even more churn.

"go get" is dependency management. It adds a dependency (module) with a specific version to your project and pins it in the go.mod file.

Yeah, I noticed myself that my information was stuck in the "good old Go times" when things were still (too) simple, and updated my statement above...

This approach to dependency management is destroying Linux distributions.

It's already making FOSS less accessible to people who are not developers.

Not to mention how quickly it rots.