HackerTrans
TopNewTrendsCommentsPastAskShowJobs

howardjohn

no profile record

comments

howardjohn
·4 ay önce·discuss
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.
howardjohn
·4 ay önce·discuss
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)
howardjohn
·4 ay önce·discuss
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.
howardjohn
·4 ay önce·discuss
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.
howardjohn
·geçen yıl·discuss
(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