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

201–207 of 207 posts

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

#201

Post by nijave »

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.

I haven't used Java much in the last few years but it was pretty straight forward with Maven with the slight caveat you use an IDE to do everything.

Python isn't too bad now-a-days with poetry although the repo spec could use more constraints

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

#202

Post by jamietanna »

anttiharju wrote: post #186
jamietanna wrote: post #185

Earlier quoted context omitted.

What's the use case you have over "just" using the official install process (`curl | sh`)?

As long as a team agrees to have .golangci-version as the source of truth, the people using the tool don't have to worry about having the right version installed, as the wrapper fetches it on demand. Having the wrong version installed between collaborators is problematic as then they may get different results and spend time wondering why. Works across branches and projects.

Interesting - would something like `make lint` (which then installs to `$PWD/bin`) work? That's how I've been doing it on the projects I've been working on, and it's worked nicely - including automated updates via Renovate (https://www.jvt.me/posts/2022/12/15/renovate-golangci-lint/)

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

#203

Post by howardjohn »

kbolino wrote: post #198
jamietanna wrote: post #176

Earlier quoted context omitted.

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

Ok, I'm trying to suss out what this means, since `go tool` didn't even exist before 1.24. The functionality of `go tool` seems to build on the existing `go run` and the latter already uses the same package compilation cache as `go build`. Subsequent invocations of `go run X` were notably faster than the first invocation long before 1.24. However, it seems that the final executable was never cached before, but now it…

(Author of the blog here (the on in this thread, not the original submission))

Great question! I wasn't aware of the 1.24 optimization when I first wrote the post, but was interested to dig into this deeper. I updated the post: https://blog.howardjohn.info/posts/go-tools-command/#digging....

The tl;dr is...: 1. The new caching impacts the new `go tool` and the existing `go run`. 2. It has a massive benefit. 3. `go tool` is a bit faster than `go run` due to skipping some module resolution phases. 4. Caching is still (relatively) slow for large packages

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

#204

Post by kbolino »

howardjohn wrote: post #203
kbolino wrote: post #198

Earlier quoted context omitted.

Ok, I'm trying to suss out what this means, since `go tool` didn't even exist before 1.24. The functionality of `go tool` seems to build on the existing `go run` and the latter already uses the same package compilation cache as `go build`. Subsequent invocations of `go run X` were notably faster than the first invocation long before 1.24. However, it seems that the final executable was never cached before, but now it…

(Author of the blog here (the on in this thread, not the original submission)) Great question! I wasn't aware of the 1.24 optimization when I first wrote the post, but was interested to dig into this deeper. I updated the post: https://blog.howardjohn.info/posts/go-tools-command/#digging... . The tl;dr is...: 1. The new caching impacts the new `go tool` and the existing `go run`. 2. It has a massive benefit. 3. `go t…

Awesome! It's interesting that there's still (what feels like) a lot of overhead from determining whether the thing is cached or not. Maybe that will be improved before the release later this month. I'm wondering too if that's down to go.mod parsing and/or go.sum validation.

I'd also note the distinction between `go run example.com/foo@latest` (which as you note must do some network calls to determine the latest version of example.com/foo) and simple `go run example.com/foo` (no @) which will just use the version of foo that's in go.mod -- presumably `go tool foo` is closer to the latter.

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

#205

Post by sunshowers »

jeffbee wrote: post #57
jrockway wrote: post #54

Earlier quoted context omitted.

Bazel prints a message when you invalidate the in-memory cache in a perhaps accidental way; you can supply it with a flag to make this an error and skip the cache invalidation. If you try to run two Bazel invocations in parallel in the same workspace, one waits for the other to be done.

I assumed they meant an error of improperly using cached results. I am sure bazel has its flaws but it assiduously avoids that.

I did mean improperly using cached results. It's merely the hardest problem in computer science :)

The sibling suggests this may still be an issue. I'm not surprised—cache invalidation is very difficult to solve, and conservative approximations like tearing down the whole process each time tend to be quite effective.

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

#206

Post by sunshowers »

spockz wrote: post #84
sunshowers wrote: post #22

Earlier quoted context omitted.

(I worked on source control at FB for many years.) The main argument for not overly genericizing things is that you can deliver a better user experience through domain-specific code. For Bazel and buck2 specifically, they require a total commitment to it, which implies ongoing maintenance work. I also think the fact that they don't have open governance is a hindrance. Google's and Meta's internal monorepos make certa…

GraalVM’s native image has been a thing for a while now. This could overcome the daemon issue partially. The daemon does more ofc by as it keeps some state in memory. But at least the binary start time is a solved problem in Java land.

Why does Bazel not ship a native image by default?

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

#207

Post by spockz »

sunshowers wrote: post #206
spockz wrote: post #84

Earlier quoted context omitted.

GraalVM’s native image has been a thing for a while now. This could overcome the daemon issue partially. The daemon does more ofc by as it keeps some state in memory. But at least the binary start time is a solved problem in Java land.

Why does Bazel not ship a native image by default?

I do not know. I could only find GitHub issues and feature sound offering integration with graalvm for building native apps with Bazel.
Post reply on HN