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

161–170 of 207 posts

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

#161

Post by verdverm »

wakawaka28 wrote: post #133
verdverm wrote: post #47

Earlier quoted context omitted.

In addition, a good dependency security scanning tool can analyze reachability to answer this question for you

That is a bit much to ask for IMO. In any case, the project may not be aware of how any given developer will use the tool. So who is to say that if you change the order of two parameters to the tool, the tool might not take a different path and proceed to hack your computer? You really don't want any of this problem. What you should ask for is for the tools' dependencies to be listed separately, and for each tool to…

> for each tool to ... "do one thing well."

There is a lot of merit to this statement, as applied to `go tool` usage and to security scanning. Just went through a big security vendor analysis and POCs. In the middle I saw Filippo Valsorda post [1] about false positives from the one stop shops, while govulncheck (language specific) did not have them. At the same time, there was one vendor who did not false positive with the reachability checks on vulns. While not always as good, one-stop-shops also add value by removing a lot of similar / duplicated work. Tradeoffs and such...

[1] https://bsky.app/profile/filippo.abyssdomain.expert/post/3ld...

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

#162

Post by caust1c »

cirwin wrote: post #69
caust1c wrote: post #60

Earlier quoted context omitted.

Having not looked at it deeply yet, why require building every time it's invoked? Is the idea to get it working then add build caching later? Seems like a pretty big drawback (bigger than the go.mod pollution, for me). Github runners are sllooooow so build times matter to me.

`go tool` doesn't require a rebuild, but it does checking that the tool is up-to-date (which requires doing at least a bit of work). This is one of the main advantages of using `go tool` over the "hope that contributors to have the right version installed" approach. As the version of the tool required by the project evolves, it continues to work. Interestingly, when I was first working on the proposal, `go run` delib…

Thanks for the explanation and contribution! Very much appreciated :-)

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

#163

Post by herval »

potamic wrote: post #110
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.

Go has been a masterclass in disparaging industry learnings as "unnecessary" (dep management, generics, null safety), then gradually bolting them into the language. It's kinda hilarious to watch.

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

#164

Post by herval »

dingnuts wrote: post #141
LinXitoW wrote: post #137

Earlier quoted context omitted.

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 "gr…

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

...yet

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

#165

Post by devmor »

potamic wrote: post #110
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.

Because everyone has their own opinion about it, like most other standards.

Personally, I think the way PHP handles dependencies is vastly preferable to every other ecosystem I've developed in, for most types of development - but I know its somewhat inflexible approach would be a headache for some small percentage of developers too.

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

#166

Post by kbolino »

gr4vityWall wrote: post #154
amukher1 wrote: post #55

Found this a lot easier to follow. https://blog.howardjohn.info/posts/go-tools-command/ And didn't quite understand the euphoria.

The feature itself seems reasonable and useful. Specially if most of your tooling is written is Go as well. But this part caught my attention: > user defined tools are compiled each time they are used Why compile them each time they are used? Assuming you're compiling them from source, shouldn't they be compiled once, and then have the 'go tool' command reuse the same binaries? I don't see why it compiles them at the…

There is a cache and they're aren't re-compiled unless they change or the cache is cleared.

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

#167

Post by rednafi »

dkarl wrote: post #149
LinXitoW wrote: post #137

Earlier quoted context omitted.

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 "gr…

Speaking as someone who comes from the opposite end of the spectrum (Scala both professionally and by personal preference) and who doesn't enjoy Go as a language, I think there's a lot to be said for a language that evolves that way. Being able to make decisions with literally years of hindsight is powerful. Looking at the top critiques here and how they've been addressed, this seems like a pretty thoroughly baked ap…

Different languages speak to different people. I feel the same way about Scala and most other functional languages. To me, they’re fun and all, but I wouldn’t build anything large-scale with them. My problem space is interesting enough that I don’t have to worry about Go being boring.

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

#168

Post by spiderice »

room271 wrote: post #145
LinXitoW wrote: post #137

Earlier quoted context omitted.

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 "gr…

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

> Java, Scala, Javascript/Typescript, Python

You seem to only use languages with bad dependency management. Which sounds tongue in cheek, but it's true. These are the languages (along with Go) where people hate the dependency management solutions.

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

#169

Post by kbolino »

rednafi wrote: post #108
catlifeonmars wrote: post #106

Earlier quoted context omitted.

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

go tool is only slower when (re-)compilation is needed, which is not often. You'd have to pay the same price anyway at some point to build the binary placed in ./bin.

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

#170

Post by room271 »

spiderice wrote: post #168
room271 wrote: post #145

Earlier quoted context omitted.

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

> Java, Scala, Javascript/Typescript, Python You seem to only use languages with bad dependency management. Which sounds tongue in cheek, but it's true. These are the languages (along with Go) where people hate the dependency management solutions.

Haha perhaps - though I think you'll find that (with the exception of Scala) these are some of the most popular programming languages.

Having sad that, I don't really know anyone with significant Go experience who dislikes its dependency management - most critiques are now quite out of date/predate current solutions by several years.

Finally, I'm not really sure which language you are proposing has better dependency management than Go - whether in relation to security, avoiding the 'diamond' problem, simplicity, etc. Rustaceans like to critique Go (no idea if you are one but my experience is that criticism is often from this crown) but I'm not sure how, from my own Rust experience/knowledge, it is actually better. In fact, I think there are several grounds to think that it is worse (even if still very solid compared to some of the aforementioned languages).

Post reply on HN