If you don't need to link C lib, you can build any combination of arch and OS for a golang program. The default tooling allows you to do so easily.

If you need to link a C lib, there are ways to set it up to compile other OS (and maybe other archs).

take numpy as an example, it's gfortran mixed with C. How does cgo handle that?

And there's ffmpeg....

If you got object files you can compile whatever if you have the compiler toolset. I have made a go program that links ffmpeg and is built from linux to Windows and Macos. It was not super easy but it's doable.

wheels, conda, docker, firecracker, unikernel, flatpak

flatpak, docker ? i.e. include an almost complete distribution just to make one package work? but what if you want that package to work in the distribution you have now? What if you need 2 different packages that are in different flatpacks or different docker images?

Set them up, each in its own container, and use GRPC to communicate between them...

(Not even kidding, I've seen people do this)

Goodness gracious!

Well, if you're using GRPC anyway, and have the protocol buffers already... It's hard to resist the temptation after a few hours of installing broken package versions.

Incidentally, I suspect this is the spiritual origin of microservoces...

obviously don't try those first I'm just saying there's a stack of options to work with for any level of isolation you desire.

start with wheels if you just want pre-built binaries, move up to conda if you need arch and OS-specific C libs that depend on system packages, flatpack or docker if you dont want those to mess up your host, or unikernel/firecracker/VMs if you need kernel modules or hardware virtualization.