author here; Using Docker saved me from creating the code to cross compile from windows->linux, darwin->linux/windows, ... And this alone was worth it, but being able to ship something that works out of the box is nice a nice bonus :) edit: I'm also planning to create macOS and iOS target images.

Docker will only let you cross-compile to OSes with the same kernel, which is relatively limited. A full set of say vagrant files would be slower, but a lot more polyvalent (but even then it would not let you, say, compile a windows binary from linux).

You can cross-compile to completely different environments. It just can be tricky to set up, so prepared docker images with e.g. the toolchain to build a Windows executable on Linux are great to have, and what is provided here.

I think it's a nice idea in theory to provide cross-compilation support by means of emulating all possible target architectures on the compiling machine.

Then I remember that I'd be managing a custom heterogenous compute cluster just to compile some code.

It's not emulation, it's cross-compilation which has existed basically forever. You don't have to target the same instruction set as the one you're compiling on.

I am well aware of that, I was referencing the concept of "cross-compilation" the GP seemed to have.

I see what you mean now, using like qemu or something. So "emulated native compilation". It is an interesting concept. Sorry for misunderstanding you.

Indeed, "virtualbox-the-crosscompiler" (probably from hell). QEMU would be a few orders of magnitude slower but I think it supports many more archs.

No hard feelings :)

As long as they provide the correct kernel headers and library headers (libc etc) for your target, it should work fine in docker.

Go doesn't really use libc all that much. Syscalls are also implemented in pure go + as, so there aren't really header files to provide. That makes for a great cross-compilation story.