In my opinion, if a language really wants to compete with Go in my space (devops/infrastructure), then it absolutely _must_ have static-linked binaries. This feature has been such a huge win, and I continue to appreciate it every time I go back to something else.
As far as I can tell Nim doesn't have statically-linked and compiled binaries out-of-the-box. Even if it wins in other language-specific features, Go will continue charging on in the infra space.
Static linking is one of the worst possible things you can do in terms of system security. When you run N applications that are all statically linked against library Foo and a 0-day drops for Foo, how does a systems administrator identify the applications that statically link against a vulnerable version of Foo and then patch it? Suddenly that sysadmin is dependent upon N upstreams to provide security fixes for a library they don't even maintain! Static linking is only feasible in the "app" world of proprietary software that gets shipped to customers without any concern for their safety.
Go is a bold step backwards in so many other ways, but this is one of the most egregious, especially since support for dynamic linking appears to be only an experimental feature.
If you have a good CI pipeline, "patching" is all automatic.
A security bugfix just got pushed for Go 1.5. Since all my apps are dockerized based on the official golang image and are built by CI, as soon as the fix was published it was included in the next commit and pushed as part of that build.
No intervention required. Similarly all dependent packages are pulled as part of the build so patches/fixes in them are automatically updated as well (note that vendoring would break this).
"as soon as the fix was published it was included in the next commit and pushed as part of that build"
Lovely for your developers, or if you're deploying it yourself as part of a service. Not so hot for people who are actually running the code you shipped them last week, on their own hardware. Monolithic statically-linked blobs aren't doing them any favors.
I would heartily disagree, as a guy that runs the code.
One of the benefits of these statically compiled binaries is that they are not coupled to each other. Everything doesn't have to be upgraded at the very same time.
There's good coupling and there's bad coupling, and a semi-famous quote about learning the wrong lesson.
"If a cat sits on a hot stove, that cat won't sit on a hot stove again. That cat won't sit on a cold stove either."
It sounds like you've been burned by bad coupling. Sure, upgrading one thing and having something else break sucks. However, having to upgrade a hundred things because that one thing that's statically linked into all of them (like your SSL library) had a bug also sucks. It's like Scylla and Charybdis. They're both bad, but it is possible to steer between them.
The dual nature of this problem was recognized decades ago. It's why we came up with things like API versions and even the symbol versioning that you probably don't realize is already supported by your system's loader. Responsible developers can use these things to make sure that compatible fixes take effect where they need to without relinking, while incompatible changes affect only new code compiled and linked with the new header files etc. That's good coupling - the kind that reduces risk and total work.
Unfortunately, responsible developers are in short supply. Worse, faced with a plethora of irresponsible developers who don't know how to make a change without breaking stuff, a lot of people are reaching for the ugly workaround - static linking, including the kind that's disguised as containers - instead of solutions that will last. They've veered away from Scylla, right into Charybdis's maw. I made that mistake once myself once - perhaps more than once - until I realized I was getting just as burned by the "solution" as I was by the original problem. I suppose more people will have to go through that same process before the situation really improves.
> Responsible developers can use these things to make sure that compatible fixes take effect where they need to without relinking, while incompatible changes affect only new code compiled and linked with the new header files etc. That's good coupling - the kind that reduces risk and total work.
I admit I do not know very much about this. Thanks for sharing! I admit I'm definitely not the most competent developer but I try.
I've yet to see any organization that is planning to be around for more that 10 years buying into this.
> all my apps are dockerized
That might be true in a 2-years old startup with 5 employees. Technologies change every few years. Linux distributions managed has been providing upgrade paths for software for two decades by unbundling components and tracking dependencies.
I've seen security issues introduced by dynamic linking too, so I don't think this is so cut-and-dry. The huge number of package updates needed when a core library has a security vulnerability is a big downside, but having programs that actually work is the upside.
Have you looked at what steam does to eliminate any system libraries from accidentally getting linked in and breaking games? This is an example of the downsides of dynamic linking.
Nim uses your C compiler to produce the final binary, so it can produce statically linked standalone programs everywhere a C compiler can (which is pretty much everywhere).
Exactly how self-contained do you want your binaries to be? Binaries built with Nim will be dynamically linked against libc, as well as any other C libraries you use (e.g. OpenSSL, PCRE), unless the Nim compiler gives you a way to pass the "-static" option to the linker. But Nim modules themselves, including the Nim standard library, are statically linked. So the resulting artifact is much more self-contained than it would be for, say, Python, Ruby, Node.js, or a JVM language.
As far as I can tell Nim doesn't have statically-linked and compiled binaries out-of-the-box. Even if it wins in other language-specific features, Go will continue charging on in the infra space.