Thanks for the link! I could have sworn this was "fixed" and was surprised testing 1.26.1 showed the same (IMO bad) behavior! Didn't realize there was a revert. https://github.com/golang/go/issues/77923 looks like a hopeful path forward.

I can admit that part was maybe a bit extreme :) fortunately in practice this would be a pretty rare situation IME due to how compatible Go is across versions.

(Blog author)

I’m afraid setting a version lower than the one you’re using means you have to setup a CI of some kind to verify compilation does indeed work for previous versions of go.

Maybe that’s why some author do not bother and put the version they are using (though I do agree it is a bad practice indeed).

Thank you for this article. If I want to be told when to upgrade, I know where to shop, i.e. Bill's Bloatware in Redmond.

I think Rust is slightly different in practice even if they behave the same technically. I'm not sure Rust lets you even set the MSRV to a specific patch which is the biggest annoyance with Go; if they do it's so uncommon I've at least never seen it. And I don't believe any Rust tooling encourages you to set the MSRV to <latest Rust version> like tools in the Go ecosystem do.

agentgateway.dev is one I have been working on that is worth a look if you are using the proxy side of LiteLLM. It's open source part of the Linux foundation.

(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

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.