Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.24's go tool is one of the best additions to the ecosystem in years

jvt.me

Post reply on HN
Print view View original

101–110 of 207 posts

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#101

Post by rednafi »

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?

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.

But what happens if I run ‘go run’ or ‘go build’? Will the tools get into the final artifact?

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.

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#102

Post by WuxiFingerHold »

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.

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#103

Post by karel-3d »

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.

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.

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 @version` in makefile. So, eh.

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#104

Post by 8n4vidtmkvmk »

verdverm wrote: post #44
silverwind wrote: post #42

Earlier quoted context omitted.

Yes, except it does not support version ranges.

Go uses Minimum Version Selection (MVS) instead of a SAT solver. There are no ranges in any go dependency specifications. It's actually a very simple and elegant algorithm for dependency version selection https://research.swtch.com/vgo-mvs

> Minimal version selection assumes that each module declares its own dependency requirements: a list of minimum versions of other modules. Modules are assumed to follow the import compatibility rule—packages in any newer version should work as well as older ones—so a dependency requirement gives only a minimum version, never a maximum version or a list of incompatible later versions.

That sounds like a non-starter. You almost never want to to unintentionally 'upgrade' to the next 'major' ver. There's also occasionally broken or hacked/compromised minor vers.

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#106

Post by catlifeonmars »

rednafi wrote: post #101

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? 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. But what happens if I run ‘go run’ or ‘go build’? Will the tools get into the final artifa…

> won’t it make the binary larger?

No. The binary size is related to the number of dependencies you use in each main package (and the dependencies they use, etc). It does not matter how many dependencies you have in your go.mod.

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#108

Post by rednafi »

catlifeonmars wrote: post #106
rednafi wrote: post #101

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? 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. But what happens if I run ‘go run’ or ‘go build’? Will the tools get into the final artifa…

> won’t it make the binary larger? No. The binary size is related to the number of dependencies you use in each main package (and the dependencies they use, etc). It does not matter how many dependencies you have in your go.mod.

Ah, thanks. This isn't much of an upgrade from the `tools.go` convention, where the tools are underscore-imported. All it does is provide an indication in the `go.mod` file that some dependencies come from tools.

Plus, `go tool ` is slower than `./bin/`. Not to mention, it doesn’t resolve the issue where tools might use a different version of a dependency than the app.

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#109

Post by arccy »

TheDong wrote: post #93

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 them…

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

Re: Go 1.24's go tool is one of the best additions to the ecosystem in years

#110

Post by potamic »

TheDong wrote: post #93

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 them…

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.
Post reply on HN