I think the main thing that's different about Go compared to more old-school languages is that the Go binary distribution includes the cross-compilers right out of the box. So anybody who can run "go build" can also cross-compile their application -- and, importantly, all of its library dependencies -- for any architecture that Go supports.

On the other hand, if you want to cross-compile a C program using GCC, you need to separately build and install a complete gcc+binutils toolchain for every individual arch that you want to target. And you have to handle the dependency management yourself, which may be tricky if your dependencies' build scripts weren't designed with cross-compilation in mind.

Golang is special because pure Go programs tend to have a closed ecosystem with its own linker (that typically don't link to libc or other C libs) so it makes static linking very easy. Other languages can certainly do static linking, but it tends to be a bit challenging to set it up on different OS's due to the need to have all needed C libs as static libs and then instruct the linker appropriately.

No. Some bytecode compiled languages are compiled and require at least an archive to be unzipped or at least the virtual machine pre installed.

Java is an example -- you'll want your your system java deployment to match the stuff stashed in your jar.

Erlang is compiled but usually releases bundle the VM up with the project, so you typically deliver a full directory with the VM packed in there.

Not dynamically linking to libc is pretty unusual. The libc-equivalent parts are in the Go runtime, statically linked.