> Production systems normally only replace shared libraries to fix vulnerabilities. So, that's a non-argument. Vulnerabilities are usually unforeseen. Which me

> Production systems normally only replace shared libraries to fix vulnerabilities. So, that's a non-argument. Vulnerabilities are usually unforeseen. Which means that upgrading a shared library---for any reason whatsoever---could introduce a new vulnerability to all programs using that library. > On non-production systems, it's far easier to replace one vulnerable library, than tens of vulnerable Go programs. That is, if you know which Go program was using what version of that package again. It's easier, but it comes with aforementioned cost. Also, relative difficulty matters here. Maybe you haven't used Go before, but that all seems pretty simple. Particularly given the tools to analyze Go programs built right into the standard library. Also, FYI, shared Go libraries are on the roadmap. That doesn't really help, but it's certainly better than "we refuse to add it."