> If your career consists of Ruby->Node.js->Go then static binaries are radical new technology.

Rather than offer what amounts to nothing more than an ad hominem, perhaps you’d care to explain why whatever you’re using is superior.

Your preference may be containers or bytecode bundles, but you’d be hard pressed to justify a major advantage and add a lot of complexity overhead for the privilege of using them.

> Rather than offer what amounts to nothing more than an ad hominem

Is this ad hominem? Why?

We can both agree to this and agree that Go's compile speed makes very large code bases possible (and that its cross-compile story is very compelling when your entire world revolves around writing on OSX machines and running in a linux docker container.

Lots of languages can deliver big static binaries. Hell, once upon a time this was considered a disadvantage and languages like Common Lisp and Smalltalk were totally raked over the coals for having an image & executable model!

> but you’d be hard pressed to justify a major advantage and add a lot of complexity overhead for the privilege of using them.

Why then is Go given this?

Because I could name 3 languages equally deserving right off the bat and one of them would be way less work: Kotlin, Swift and Haskell.

I disagree. Go's binaries are a 'radical new concept' in making them both the default and easy to use. Sure you can do it in C, sometimes, with the right libraries. But many won't even work statically.

You can do it in any programming language that has compilers to native code, it was the default linking model in OSes until the mid-90's and still is on the embedded space.

The special case of glibc, is the exception of majority of C compilers.

I'm well aware. But keep in mind probably the majority of us were not writing software in the early 90s(no offense intended). We grew up in a world with Java, Python, and Perl...none of which weren't even capable of doing so. Sure C and C++ were around too, but of course not as 'hot', neither encouraged static linking, and as mentioned, sometimes weren't even capable of doing so depending on library.

The static libraries are only popular right now because people who don't need static cross-compiled binaries are convinced they need a computer that is exactly like the computer people who make websites need.

It's a very odd state of affairs. In an age of docker, nix uberjars, ever more sophisticated user and system space filesystems it's really questionable what value they bring.

People say, "Simplicity" then they bling out their docker containers with multiple layers of processes and initialization anyways.

Go's tooling would have been great in a pre-Docker era. Now... I don't see the appeal.

Well, keep in mind that Go also predates Docker by a bit. Docker really did solve the whole dependency issue of dynamic languages/runtimes, but Go still has a possible advantage here - it can be built in a much smaller container..even SCRATCH. A minor convenience at best, but something.