5 ms·

I think it's a bad addition since it pushes people towards a worse solution to a common problem. Using "go tool" forces you to have a bunch of dependencies in

I think it's a bad addition since it pushes people towards a worse solution to a common problem. Using "go tool" forces you to have a bunch of dependencies in your go.mod that can conflict with your software's real dependency requirements, when there's zero reason those matter. You shouldn't have to care if one of your developer tools depends on a different version of a library than you. It makes it so the tools themselves also are being run with a version of software they weren't tested with. If, for example, you used "shell.nix" or a dockerfile with the tool built from source, the tool's dependencies would match it's go.mod. Now they have to merge with your go.mod... And then, of course, you _still_ need something like shell.nix or a flox environment (https://flox.dev/ https://flox.dev/) since you need to control the version of go, control the version of non-go tools like "protoc", and so you already have a better solution to downloading and executing a known version of a program in most non-trivial repos.

Defletter 2y ago
> Using "go tool" forces you to have a bunch of dependencies in your go.mod that can conflict with your software's real dependency requirements, when there's zero reason those matter. You shouldn't have to care if one of your developer tools depends on a different version of a library than you. Heh, were the people who made 'go tool' the same people who made Maven? Would make sense :P
- larusso 2y ago
  At least build time dependencies are separated from runtime dependencies.
arccy 2y ago
control the go version with the `toolchain` directive, replace protoc with buf.build (which is way better anyway).
potamic 2y ago
Why do ecosystems continue to screw up dependency management in 2025? You would think the single most widely used feature by programmers everywhere would be a solved problem by now.
- LinXitoW 2y ago
  Go launched without any dependency management. Go people believe that anything non-trivial is either a useless abstraction, or too difficult for the average developer. So their solution is to simply not add it, and tell anyone claiming to need it that their mind has been poisoned by other languages... Until that time when they realize everyone else was right, and they add an over simplified, bad solution to their "great" language.
  - dingnuts 2y ago
    If you don't like Go, why did you come and comment in this thread? didn't your mother ever tell you that if you don't have something nice to say, you shouldn't say anything? at least Go doesn't have virtualenvs
    - herval 2y ago
      ...yet
  - room271 2y ago
    Your reply is polemical and somewhat detached from the experience of working with Go. From my experience, Go's dependency management is far better than anything else I've worked with (across languages including Java, Scala, Javascript/Typescript, Python). Your criticism is perhaps relevant in relation to language features (though I would disagree with your position) but has no basis in relation to tooling and the standard library, both of which are best in class.
    - larusso 2y ago
      I think in this case you should give rust a try if only for cargo. Because the mentioned issues are non existent there. Also because it’s the language mostly referred to as being completely on the other side of the spectrum when it comes to language design philosophy.
      - 2y ago
peterldowns 2y ago
I agree — tools should be shared artifacts that the team downloads and can guarantee are the same for everyone. I usually setup a flake.nix for everyone but flox, earthly, devenv, jetify, are all great alternatives. Ideally your tools are declaratively configured and shared between your team and your CI/CD environment, too. The `go tool` stuff has always seemed like a junior engineering hack — literally the wrong tool for the job, yeah sure it gets it working, but other than that it's gross.
- arccy 2y ago
  well now it leans in to go's reproducible tooling so it's declaratively configured and shared between your team and your CI/CD environment too.
  - peterldowns 2y ago
    There are many tools that arent written in golang, and therefore not manageable via this approach. I don’t really understand why I would use this.
deleted 2y ago
[deleted]
mseepgood 2y ago
> Using "go tool" forces you to have a bunch of dependencies in your go.mod No, it doesn't. You can use "go tool -modfile=tools.mod mytool" if you want them separate.
- jen20 2y ago
  This should almost certainly be the default recommendation.
- jcmfernandes 2y ago
  I built a simple tool to generate binstubs and work around this problem: https://github.com/jcmfernandes/go-tools-binstubs https://github.com/jcmfernandes/go-tools-binstubs However, having multiple tools share a single mod file still proves problematic occasionally, due to incompatible dependencies.
- nijave 2y ago
  That seems like it should have been the default
nixosbestos 2y ago
I ask this out of curiosity, not accusation, do you work for Flox? Can't say I've ever seen it mentioned "in the wild".
- carlthome 2y ago
  Hehe, I was also wondering this.
- TheDong 2y ago
  I do not, just aware of it as a hip tool in the general space of "I want to install and version tools per-project, but I don't want to learn the nix programming language"
jchw 2y ago
Yep, unfortunately this concern was mostly shrugged off by the Go team when it was brought up (because it would've required a lot of work to fix IIRC, which I think is a bad excuse for such a problem). IMO, a `go tool` dependency should've worked exactly the same way that doing `go install ...` works with a specific @tag: it should resolve the dependencies for that tool completely independently. Because it doesn't, you really, really shouldn't use this mechanism for things like golangci-lint, unfortunately. In fact, I honestly just recommend not using it at all...
- arccy 2y ago
  i think it's more an argument to not use the dumpster fire that is golangci-lint
  - jchw 2y ago
    No, it really is a problem with this design and not an issue with golangci-lint. The trouble is that MVS will happen across all of your dependencies, including direct and other tool dependencies. If everything very strictly followed Go's own versioning guidelines, then this would be OK since any breaking change would be forced off into a separate module identity. However, even Google's own modules don't always follow this rule, so in reality it's just kind of unrealistic. You don't need something huge like golangci-lint to run into problems. It's just easier to see it happen because the large number of dependencies makes it a lot more likely.
  - anttiharju 2y ago
    I've been working on a version manager for golangci-lint in the quiet moments [1] It already works, but it's work in progress. Happy to get feedback [1] https://github.com/anttiharju/vmatch https://github.com/anttiharju/vmatch
    - jamietanna 2y ago
      What's the use case you have over "just" using the official install process (`curl | sh`)?

Defletter 2y ago

> Using "go tool" forces you to have a bunch of dependencies in your go.mod that can conflict with your software's real dependency requirements, when there's zero reason those matter. You shouldn't have to care if one of your developer tools depends on a different version of a library than you. Heh, were the people who made 'go tool' the same people who made Maven? Would make sense :P

larusso 2y ago
At least build time dependencies are separated from runtime dependencies.

arccy 2y ago

control the go version with the `toolchain` directive, replace protoc with buf.build (which is way better anyway).

potamic 2y ago

Why do ecosystems continue to screw up dependency management in 2025? You would think the single most widely used feature by programmers everywhere would be a solved problem by now.

LinXitoW 2y ago
Go launched without any dependency management. Go people believe that anything non-trivial is either a useless abstraction, or too difficult for the average developer. So their solution is to simply not add it, and tell anyone claiming to need it that their mind has been poisoned by other languages... Until that time when they realize everyone else was right, and they add an over simplified, bad solution to their "great" language.
- dingnuts 2y ago
  If you don't like Go, why did you come and comment in this thread? didn't your mother ever tell you that if you don't have something nice to say, you shouldn't say anything? at least Go doesn't have virtualenvs
  - herval 2y ago
    ...yet
- room271 2y ago
  Your reply is polemical and somewhat detached from the experience of working with Go. From my experience, Go's dependency management is far better than anything else I've worked with (across languages including Java, Scala, Javascript/Typescript, Python). Your criticism is perhaps relevant in relation to language features (though I would disagree with your position) but has no basis in relation to tooling and the standard library, both of which are best in class.
  - larusso 2y ago
    I think in this case you should give rust a try if only for cargo. Because the mentioned issues are non existent there. Also because it’s the language mostly referred to as being completely on the other side of the spectrum when it comes to language design philosophy.
    - 2y ago

peterldowns 2y ago

I agree — tools should be shared artifacts that the team downloads and can guarantee are the same for everyone. I usually setup a flake.nix for everyone but flox, earthly, devenv, jetify, are all great alternatives. Ideally your tools are declaratively configured and shared between your team and your CI/CD environment, too. The `go tool` stuff has always seemed like a junior engineering hack — literally the wrong tool for the job, yeah sure it gets it working, but other than that it's gross.

arccy 2y ago
well now it leans in to go's reproducible tooling so it's declaratively configured and shared between your team and your CI/CD environment too.
- peterldowns 2y ago
  There are many tools that arent written in golang, and therefore not manageable via this approach. I don’t really understand why I would use this.

deleted 2y ago

[deleted]

mseepgood 2y ago

> Using "go tool" forces you to have a bunch of dependencies in your go.mod No, it doesn't. You can use "go tool -modfile=tools.mod mytool" if you want them separate.

jen20 2y ago
This should almost certainly be the default recommendation.
jcmfernandes 2y ago
I built a simple tool to generate binstubs and work around this problem: https://github.com/jcmfernandes/go-tools-binstubs https://github.com/jcmfernandes/go-tools-binstubs However, having multiple tools share a single mod file still proves problematic occasionally, due to incompatible dependencies.
nijave 2y ago
That seems like it should have been the default

nixosbestos 2y ago

I ask this out of curiosity, not accusation, do you work for Flox? Can't say I've ever seen it mentioned "in the wild".

carlthome 2y ago
Hehe, I was also wondering this.
TheDong 2y ago
I do not, just aware of it as a hip tool in the general space of "I want to install and version tools per-project, but I don't want to learn the nix programming language"

jchw 2y ago

Yep, unfortunately this concern was mostly shrugged off by the Go team when it was brought up (because it would've required a lot of work to fix IIRC, which I think is a bad excuse for such a problem). IMO, a `go tool` dependency should've worked exactly the same way that doing `go install ...` works with a specific @tag: it should resolve the dependencies for that tool completely independently. Because it doesn't, you really, really shouldn't use this mechanism for things like golangci-lint, unfortunately. In fact, I honestly just recommend not using it at all...

arccy 2y ago
i think it's more an argument to not use the dumpster fire that is golangci-lint
- jchw 2y ago
  No, it really is a problem with this design and not an issue with golangci-lint. The trouble is that MVS will happen across all of your dependencies, including direct and other tool dependencies. If everything very strictly followed Go's own versioning guidelines, then this would be OK since any breaking change would be forced off into a separate module identity. However, even Google's own modules don't always follow this rule, so in reality it's just kind of unrealistic. You don't need something huge like golangci-lint to run into problems. It's just easier to see it happen because the large number of dependencies makes it a lot more likely.
- anttiharju 2y ago
  I've been working on a version manager for golangci-lint in the quiet moments [1] It already works, but it's work in progress. Happy to get feedback [1] https://github.com/anttiharju/vmatch https://github.com/anttiharju/vmatch
  - jamietanna 2y ago
    What's the use case you have over "just" using the official install process (`curl | sh`)?