We used that to make a simple "VPN diagnostics" app for our helpdesk (app checked connectivity and config of the machine then displayed the summary page). Only thing that needed to be written per-os is how to call a browser to display the report

interesting. could you share what specifically the report had?

I made a cool program for Go projects that will compile all the supported OS and ARCH combos for your code. Please try it :) I use it for everything I make now.

Just do `release --name "mycoolprogram" --version "0.1.0"`

and it will output all of your labeled release binaries for every platform your code supports.

check it out! [0] You can see it at work here for this simple markdown blog generator I made, which sports 40 different platform combos [1]

[0] - https://github.com/donuts-are-good/release.sh

[1] - https://github.com/donuts-are-good/bearclaw/releases/latest

looks a heck of a lot simpler than goreleaser! I love goreleaser but it gets outrageously complicated.

Thanks for checking it out :) I'm not going to pretend I haven't been refreshing the page waiting for bugs and comments

So I always assumed this was the case for other compiled languages. Is this something special in Golang and/or recently created languages?

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.

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.

On top of this, with java, the jvm is itself dynamically linked to libc most of the time.

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.

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