Thread for discussing work on some Golang-related issues, particularly performance ones. cc @gorgeous-winter-99296 @purple-plastic-57801 who mentioned interest in this topic, and @powerful-scooter-95162, @victorious-wire-62055 who reported some of the issues.

Re the first, I think there's two parts: first is that looking up system tools should never be cached on failure. Second is that the go toolchain should be pants-provided... Both seem interesting to me and aligned with other things I've thought about for Rust and elsewhere. And I want to look at a pants-hosted c/cxx compiler soon too, and there's sharp corners with the sandboxes there atm.

And there is this big one: https://github.com/pantsbuild/pants/issues/16445 (Don't require users of one language to install a toolchain for other languages)

I’ll happily help out here, even if it’s just trying potential fixes on a real-world Go codebase. I’ve tried to figure the performance issues out on and off for a while (see #19053), but I feel that I lack the deeper knowledge of Pants internals in order to make any meaningful progress.

I'd love to get these sorted out, and we can offer guidance with the internals

I can take a look at 20274 this weekend.

The solution is schematically straightforward at least, but may or may not be "easy"

I'm also available to reproduce my issue, and I've similarly been poking at the pants codebase to understand what I might change. And this is probably a separate thread, but I tried moving the

go mod

download pieces to a named_cache only to be tripped up in getting digests to summarize those files once they're outside of the sandbox.

Fwiw (and mirroring what I do for Rust) once they're in a named cache they don't need any digests, because they wouldn't belong to a sandbox. You'd simply point GOROOT (or whatever it'd affect) at the named cache directory.

Sorry folx. Came down with covid and that took me out for a bit =(

Hope you're better now!