I think it's a bad addition since it pushes people towards a worse solution to a common problem.<p>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.<p>It makes it so the tools themselves also are being run with a version of software they weren't tested with.<p>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.<p>Now they have to merge with your go.mod...<p>And then, of course, you _still_ need something like shell.nix or a flox environment (<a href="https://flox.dev/" rel="nofollow">https://flox.dev/</a>) 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.
Found this a lot easier to follow. <a href="https://blog.howardjohn.info/posts/go-tools-command/" rel="nofollow">https://blog.howardjohn.info/posts/go-tools-command/</a><p>And didn't quite understand the euphoria.
I always think it's a shame that these features end up getting built into ecosystem-specific build tools. Why do we need separate build systems for every language? It seems entirely possible to have build system that can do all this stuff for every language at once.<p>From my experience at Google I _know_ this is possible in a Megamonorepo. I have briefly fiddled with Bazel and it seems there's quite a barrier to entry, I dunno if that's just lack of experience but it didn't quite seem ready for small projects.<p>Maybe Nix is the solution but that has barrier to entry more at the human level - it just seems like a Way of Life that you have to dive all the way into.<p>Nonetheless, maybe I should try diving into one or both of those tools at some point.
This seems handy, but often the tools run by `go generate` are outside of the Go ecosystem, or need to be binaries.<p>So I think a general solution would work better, and not be limited to Go. There are plenty of tools in this space to choose from: mise, devenv, Nix, Hermit, etc.
I like that Go decided to natively support this. But since it’s keeping the dev dependencies in the same go.mod, won’t it make the binary larger?<p>In Python’s uv, the pyproject.toml has separate sections for dev and prod dependencies. Then uv generates a single lock file where you can specify whether to install dev or prod deps.<p>But what happens if I run ‘go run’ or ‘go build’? Will the tools get into the final artifact?<p>I know Python still doesn’t solve the issue where a tool can depend on a different version of a library than the main project. But this approach in Go doesn’t seem to fix it either. If your tool needs an older version of a library, the single go.mod file forces the entire project to use the older version, even if the project needs—or can only support—a newer version of the dependency.
I don't understand why it's a good idea to couple tooling or configuration or infrastructure (e.g. Aspire.NET, which I'm also not convinced of being a good idea) so tightly with the application. An application should not need to be aware of how whatever tools are implemented or how configuration or infrastructure is managed. The tooling should point to the application as dependency. The application should not have any dependency on tooling.
A note for the author in case they are reading: "i.e." means "that is", "e.g." means "for example". You should be able to substitute these meanings and find the sentence makes sense. In all cases here you wanted "e.g.".
I appreciate that "tools" that are used to build the final version of a module/cli/service are explicitly managed through go.mod.<p>I really dislike that now I'm going to have two problems, managing other tools installed through a makefile, e.g. lint, and managing tools "installed" through go.mod, e.g. mocks generators, stringify, etc.<p>I feel like this is not a net negative on the ecosystem again. Each release Golang team adds thing to manage and makes it harder to interact with other codebases. In this case, each company will have to decide if they want to use "go tool" and when to use it. Each time I clone an open source repo I'm going to have to check how they manage their tools.
My current approach has been setting GOBIN to a local project bin via direnv and go installing bins there. install commands themselves are cached by me with a naive checksum check for the install script itself when I run my commands. Therefore all `go install`s run in parallel if I edit the install script, and go decides what to reinstall or not. At this point I don't feel it's worth migrating to `go tool` having this setup, we'll see when it's stable
what is also concerning, Go team years ago did small vote, small survey of positive occurrences, and decided to enforce it globally for anyone.<p>old design give people option to use `tools.go` approach, or other, or nothing at all. now they are enforcing this `tools.go` standard. Go looks to be moving into very restrictive territories.<p>what about surveying opposing views? what about people who did not use `tools.go`<p>what is going on in Google, Go team?
Funny to see a little go library you wrote [1] show up in a blog post years later. I need to update it now that go has iterators and generics.<p>Another great blog post [2] covers performance issues with go tool<p>[1] <a href="https://github.com/dprotaso/go-yit">https://github.com/dprotaso/go-yit</a><p>[2] <a href="https://blog.howardjohn.info/posts/go-tools-command/" rel="nofollow">https://blog.howardjohn.info/posts/go-tools-command/</a>
It doesn't look like much of an improvement over `tools/tools.go` with blank imports like this:<p>```
//go:build tools<p>package tools<p>import (
_ "github.com/xxx/yyy"
...
)
```
I don't love the pollution in the go.mod or being forced to have multiple files to track dependencies.<p>Being able to run tools directly with go generate run [1] already works well enough and I frankly don't need see any benefits compared to it in this new approach.<p>[1] <a href="https://github.com/golang/go/issues/42088">https://github.com/golang/go/issues/42088</a>
proposal is closed and accepted by Go team. [~sigh]<p>you can still leave comments in discussion issue: <a href="https://github.com/golang/go/issues/48429">https://github.com/golang/go/issues/48429</a>
I don't like this. When I install a tool, I want to use it with their dependency versions at the moment they released it.<p>When I use `go tool`, it uses whatever I have in go.mod; and, in the opposit way, it will update my go.mod for no real reason.<p>But some people do this right now with tools.go, so... whatever, it's a better version of tools.go pattern. And I can still do it my preffered way with `go install <tool>@version` in makefile. So, eh.
Since i started using nix devShells this is kind of useless.
What if i have 1 tool that isn't go tool so what do i do with it? so i have that one "exception" and here we go again...
I wish Go Team would focus on performance rather thann adding new features that nobody asked for. The http stack is barely able to beat NodeJS these days, ffs.
I have tested it and probably will use it but the fact that it pollutes your go.mod's indirect dependency list (without any distinction indicating it's for a tool) is very annoying.
go.mod and the golang tooling is a horror show. I absolutely LOVE the language, but dealing with the tooling is horrendous. I should blog about the specifics, but if you want a short version:<p>* not using posix args<p>* obscure incantations to run tests<p>* go.mod tooling is completely non-deterministic and hard to use, they should have just left the old-style vendor/ alone (which worked perfectly) and wrapped a git-submodules front-end on top for everyone who was afraid of submodules. Instead they reinvented this arcane new ecosystem.<p>If you want to rewrite the golang tooling, I'll consult on this for free.
As someone who’s been using Go since 2013 at commpanies like Apple, Microsoft, and Uber, this all seems quite unnecessary.<p>That said, if it helps people do “their thing” in what they believe is an easier (more straightforward) way, then I welcome the new changes.