undefined | Better HN

0 pointshowardjohn1y ago0 comments

(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

0 comments

kbolino1y ago

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.

j / k navigate · click thread line to collapse

0 pointshowardjohn1y ago0 comments

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

0 comments

kbolino1y ago

j / k navigate · click thread line to collapse