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

171–180 of 207 posts

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

#171

Post by room271 »

larusso wrote: post #156
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…

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.

I have no beef with Rust, but objectively I think it's dependency management, general tooling, and standard library are significantly worse than Go's. The language, as you say, has a quite different philosophy from Go which many favour - but that is only part of the story.

Could you elucidate which of the 'mentioned issues' you think are present for Go (in relation to tooling) that do not apply to Rust/cargo? Is your critique based solely on the new `go tool` command or more widespread? And are you aware that the parent criticism is at least partially misguided given it is possible to store tooling in a separate .mod file or simply ignore this feature altogether?

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

#172

Post by arccy »

jchw wrote: post #136
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…

Yep, unfortunately this concern was mostly shrugged off by the Go team when it was brought up (because it would've required a lot of work to fix IIRC, which I think is a bad excuse for such a problem). IMO, a `go tool` dependency should've worked exactly the same way that doing `go install ...` works with a specific @tag: it should resolve the dependencies for that tool completely independently. Because it doesn't, y…

i think it's more an argument to not use the dumpster fire that is golangci-lint

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

#173

Post by jchw »

arccy wrote: post #172
jchw wrote: post #136

Earlier quoted context omitted.

Yep, unfortunately this concern was mostly shrugged off by the Go team when it was brought up (because it would've required a lot of work to fix IIRC, which I think is a bad excuse for such a problem). IMO, a `go tool` dependency should've worked exactly the same way that doing `go install ...` works with a specific @tag: it should resolve the dependencies for that tool completely independently. Because it doesn't, y…

i think it's more an argument to not use the dumpster fire that is golangci-lint

No, it really is a problem with this design and not an issue with golangci-lint.

The trouble is that MVS will happen across all of your dependencies, including direct and other tool dependencies. If everything very strictly followed Go's own versioning guidelines, then this would be OK since any breaking change would be forced off into a separate module identity. However, even Google's own modules don't always follow this rule, so in reality it's just kind of unrealistic.

You don't need something huge like golangci-lint to run into problems. It's just easier to see it happen because the large number of dependencies makes it a lot more likely.

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

#174

Post by dkarl »

rednafi wrote: post #167
dkarl wrote: post #149

Earlier quoted context omitted.

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.

To be clear, I mean "boring" in the positive engineering sense of well-defined and reliable. The kind of work that I don't like to do in Go is "interesting" in the negative sense of lots of special cases, complicated branching based on combinations of data, complicated error handling... stuff where pattern matching and use of types like Option and Either shine (hell, even exception handling helps!) Basically the kind of stuff that good engineers would design out of existence if the product managers and salespeople would let us.

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

#175

Post by larusso »

room271 wrote: post #171
larusso wrote: post #156

Earlier quoted context omitted.

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.

I have no beef with Rust, but objectively I think it's dependency management, general tooling, and standard library are significantly worse than Go's. The language, as you say, has a quite different philosophy from Go which many favour - but that is only part of the story. Could you elucidate which of the 'mentioned issues' you think are present for Go (in relation to tooling) that do not apply to Rust/cargo? Is your…

Each rust crate is compiled on their own. Means if a library you pull in, needs the same crate as a another dependency, even with incompatible versions, it doesn’t matter. Then cargo understands the difference between test and build dependencies next to the dependencies for the actual lib/binaries.

The fact that each library and its dependencies gets compiled separately adds quite a lot in build time depending how many crates you reference. But you usually don‘t fight with dependency version issues. The only thing which is not expressed in crates is the minimum rust version needed. This is a pain point when you want or need to stay on a specific toolchain version. Because transient dependencies are defined by default like „major.minor.patch“ without any locking, cargo will pull the latest compatible version during an update or fresh checkout (means anything that is still compatible in terms of semantic versioning; e.g 1.1.0 means resolve a version that is >= 1.1.0 && < 2.0.0) And because toolchain version updates usually happen as minor updates it happens that a build suddenly fails after an update. Hope this makes sense.

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

#176

Post by jamietanna »

kbolino wrote: post #166
gr4vityWall wrote: post #154

Earlier quoted context omitted.

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.

cached* as of Go 1.24, prior to that they were re-compiled each time

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

#177

Post by anttiharju »

arccy wrote: post #172
jchw wrote: post #136

Earlier quoted context omitted.

Yep, unfortunately this concern was mostly shrugged off by the Go team when it was brought up (because it would've required a lot of work to fix IIRC, which I think is a bad excuse for such a problem). IMO, a `go tool` dependency should've worked exactly the same way that doing `go install ...` works with a specific @tag: it should resolve the dependencies for that tool completely independently. Because it doesn't, y…

i think it's more an argument to not use the dumpster fire that is golangci-lint

I've been working on a version manager for golangci-lint in the quiet moments [1]

It already works, but it's work in progress. Happy to get feedback

[1] https://github.com/anttiharju/vmatch

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

#178

Post by pqb »

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…

> In Python’s uv, the pyproject.toml has separate sections for dev and prod dependencies.

If you want, you can have multiple ".mod" files and set "-modifle=dev-env.mod" every time you run "go" binary with "run" or "build" command. For example, you can take what @mseepgood mentioned:

> go tool -modfile=tools.mod mytool

Plus, in last versions of the Go we have workspaces [0][1]. It is yet another way to easily switch between various environments or having isolated modules in the monorepo.

[0]: https://go.dev/blog/get-familiar-with-workspaces

[1]: https://go.dev/doc/tutorial/workspaces

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

#179

Post by int_19h »

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…

Go is more like "decades in hindsight", though. Literally the case with generics, just to give you one example - and for all the talk about how other languages aren't doing it right and they're waiting to figure it out, the resulting design is exactly the same as those other languages, except that now they had to bolt it onto the language that evolved without them for a decade, with all the inconsistencies this creates.

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

#180

Post by int_19h »

hu3 wrote: post #121
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.

nodejs' v8 has millions of man hours spent in optimzation alone since half the internet frontend runs on v8, if not more. Go being garbage collected and still beating v8 is one hell of an achievement. If you need faster Go Http you're using the wrong tool.

Go is a statically typed, AOT-compiled language, unlike V8. The kind of task that had countless hours of R&D poured into it for decades, much of it public research and open source code.

I'm not sure how GC is relevant here at all given that JS is also a garbage-collected language.

Post reply on HN