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

141–150 of 207 posts

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

#141

Post by dingnuts »

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…

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

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

#142

Post by remram »

nikolayasdf123 wrote: post #97
nikolayasdf123 wrote: post #67

Earlier quoted context omitted.

a bit worse. it is all mixed up. to keep separate dependency tree for tools need use old approach with go.mod. it is actually even worse now.

UPD: 1. it is single tree 2. BUT tools will not propagate through the dependency tree downstream due to go module pruning check this comment: https://github.com/golang/go/issues/48429#issuecomment-26184... official docs: https://tip.golang.org/doc/modules/managing-dependencies#too... > Due to module pruning, when you depend on a module that itself has a tool dependency, requirements that exist just to satisfy that to…

"usually"?

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

#143

Post by jcmfernandes »

mseepgood wrote: post #129
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 No, it doesn't. You can use "go tool -modfile=tools.mod mytool" if you want them separate.

I built a simple tool to generate binstubs and work around this problem: https://github.com/jcmfernandes/go-tools-binstubs

However, having multiple tools share a single mod file still proves problematic occasionally, due to incompatible dependencies.

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

#144

Post by teeray »

9rx wrote: post #85
teeray wrote: post #5

Earlier quoted context omitted.

Given Go’s approach to “metaprogramming” has long relied on tools written in Go, this does seem like a feature gap that needed closing. Even the introduction of `go generate` long ago formalized this approach, but still left installing the tools as an exercise for the reader. You can’t have consistent code gen if you don’t have consistent tooling across a team/CI.

> Even the introduction of `go generate` long ago formalized this approach It did, but if you recall it came with a lot of "We have no idea why you need this" from Pike and friends. Which, of course, makes sense when you remember that they don't use the go toolchain inside Google. They use Google's toolchain, which already supports things like code generation and build dependency management in a far more elegant way.…

> if you recall it came with a lot of "We have no idea why you need this" from Pike and friends

The blog post and design document both authored by Rob Pike at the time[0] contains none of that sentiment. The closest approach comes from the blog post which states:

> Go generate does nothing that couldn’t be done with Make or some other build mechanism, but it comes with the go tool—no extra installation required—and fits nicely into the Go ecosystem.

This, taken alone, would seem to support “we have no idea why you need this,” until you read the hope from the design document:

> It is hoped, however, that it may replace many existing uses of make(1) in the Go repo at least.

These are not words of someone who doesn’t understand why users would need this.

Also, I am at a FAANG and my experience differs from the parent—`go tool` is sorely needed by my teams.

[0] https://go.dev/blog/generate

[1] https://go.googlesource.com/proposal/+/refs/heads/master/des...

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

#145

Post by room271 »

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…

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.

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

#146

Post by Cthulhu_ »

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 isn't exactly true, as the dependency management was simple - clone the relevant project. Dependencies being source is great as it encourages open source.

Of course, the problem with that was that it was pretty much impossible to version properly, causing breakages and such.

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

#147

Post by gqgs »

I don't love the pollution in the go.mod or being forced to have multiple files to track dependencies.

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.

[1] https://github.com/golang/go/issues/42088

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

#148

Post by Cthulhu_ »

pjmlp wrote: post #76

This has been a thing in dotnet tool for years, now.

I think it's great that there's prior art that can be used as examples, proof of value, and opportunities for learning. I commend .NET for investing the resources in researching and developing this feature.

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

#149

Post by dkarl »

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…

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

I would rather scratch my eyes out than use Go for the kind of code I write day-to-day, but Go looks amazing for the kinds of things where you can achieve high levels of boringness, which is what we should all be striving for.

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

#150

Post by Cthulhu_ »

dankobgd wrote: post #124

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

This is actually a valid downside of Go, in that it has its own set of tools for things like debugging and whatnot instead of being compatible with existing tools.
Post reply on HN