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

151–160 of 207 posts

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

#151

Post by Thaxll »

LinXitoW wrote: post #137
potamic wrote: post #110

Earlier quoted context omitted.

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

go mod is best in class dependecy manager, it is way better than what most mainstream languages have, it's not even close.

I worked with C++/ruby/python/js/java and C#, go mod is superior to all them.

The one that is similar is Cargo ( rust ).

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

#152

Post by Cthulhu_ »

indulona wrote: post #107

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.

The Go HTTP stack is not optimized for raw performance though; there's a number of alternative HTTP stacks written in Go optimized for performance, like fasthttp (https://github.com/valyala/fasthttp). (source: https://www.techempower.com/benchmarks/)

Likewise, the standard library NodeJS http stack will not be as performant as a performance optimized alternative.

That said, if raw performance is your primary concern, neither Go nor NodeJS will be good enough. There's many more factors to consider.

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

#154

Post by gr4vityWall »

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 time you run the tool, rather than when you're installing dependencies. The benchmarks show a significant latency increase. The author also provided a different approach which doesn't seem to have any obvious downsides, besides not sharing dependency versions (which may or may not be a good thing - that's a separate discussion IMO).

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

#155

Post by JeffMcCune »

broeng wrote: post #132
Ferret7446 wrote: post #83

Earlier quoted context omitted.

This take absolute boggles the mind. You don't want people compiling your code with different versions of tools so you have to debug thousands of potential combinations of everything. You don't want people running different versions of formatters/linters that leave conflicting diffs throughout your commit history.

Tbh, I think you missed this part: "[..] mixed with artefact dependencies itself".

An artifact depends on the tools used to build it.

This is why we pin versions. Go tool is common sense, allowing for any old tool version in the build chain invites failure.

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

#156

Post by larusso »

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…

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.

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

#157

Post by pragma_x »

LinXitoW wrote: post #137
potamic wrote: post #110

Earlier quoted context omitted.

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

This situation has improved over the last 9+ years or so. I agree that's where things started and I felt much the same way at the time.

That said, I still strongly dislike that the Go ecosystem conflates a library's repo URL with it's in-language URI. Having `github.com` everywhere in your sourcecode just ignores other use-cases for dependency management, like running an artifactory in an enterprise setting. My point being: there's still room for improvement.

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

#158

Post by larusso »

Defletter wrote: post #95
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…

> 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

At least build time dependencies are separated from runtime dependencies.

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

#160

Post by pragma_x »

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.

Exactly. You lose build isolation for those tools, but you have the convenience of shipping something tested and proven (ideally) alongside the project they support. At the same time, this mess all stays isolated from the parent environment which may be the bigger fight that devs have on their hands - not everyone is using Nix or container isolation of some sort.

I also see this as sugar for `go build` or even `go run`. Or as something way easier than the `go generate` + `//go:generate go run` hack. So we can look at this as a simple refinement for existing practices.

Post reply on HN