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.
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.
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).
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.
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.
"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.
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.
> 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.
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.
https://www.schipplock.software/p/static-linking-with-nim.ht...
Googling a bit finds more on the subject, for example to go very small: