6 ms·

I never liked "go get" approach to dependency management in Go. It always seemed wrong. Even npm or maven got it better. On the other hand, deprecating a criti

I never liked "go get" approach to dependency management in Go. It always seemed wrong. Even npm or maven got it better. On the other hand, deprecating a critical tool of infrastructure leaves a sour taste. Many people would be pissed of. Better not including it in the first place. IMHO such tooling should not be part of the language itself, and be left to the community.

mikepurvis 5y ago
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.
- throwaway894345 5y ago
  See also C and C++.
cortesoft 5y ago
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.
marvinblum 5y ago
> 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.
- samcal 5y ago
  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 ;)
rob74 5y ago
"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.
- mseepgood 5y ago
  "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.
  - rob74 5y ago
    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...
goodpoint 5y ago
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.

mikepurvis 5y ago

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.

throwaway894345 5y ago
See also C and C++.

cortesoft 5y ago

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.

marvinblum 5y ago

> 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.

samcal 5y ago
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 ;)

rob74 5y ago

"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.

mseepgood 5y ago
"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.
- rob74 5y ago
  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...

goodpoint 5y ago

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.