Sure, static linking and the like make the initial deployment much easier. On the other hand, it also means that any bugs in the dependencies are baked into each application, and fixing those bugs (which may be critical security issues) requires rebuilding all the downstream code. Provided, that is, you can rebuild the downstream code. Users of closed-source binaries are simply out of luck.
Mixing multiple versions of the same (or closely related) libraries in the same program remains an issue even with self-contained applications. It might work out if the users of each version are isolated from each other, at the cost of program size and attack surface, but say you're using PyCrypto in one module and PyCryptodome in another, and you want to pass configuration or key information between them—the types won't match up. You'll also have two different API styles to deal with for the same tasks, which is bad for maintainability, which is ultimately bad for the user because it create more opportunities for bugs and makes it harder to implement new features and enhancements.
> On the other hand, it also means that any bugs in the dependencies are baked into each application, and fixing those bugs (which may be critical security issues) requires rebuilding all the downstream code.
I'm afraid I don't buy that argument at all.
Because Python is either the same or worse.
You've got the potential bugs in the Python code itself, and then the potential bugs in the random Python dependencies. You've got a whole stack of potential bugs there.
P.S. What's that nonsense about "closed-source" Go binaries ? If its an open-source project then its open-source until its compiled ! If the code's on Github then you can clone it and do as you please if you're not happy with the author's Go code.
No, you update a python library and it works for everything importing it. The point is that you can fix vulnerabilities in unmaintained apps with a simple update if the vulnerabilities are just in dependencies.
> P.S. What's that nonsense about "closed-source" Go binaries ?
The discussion is about passing around binaries and nothing else.
In practice the apps that don’t publish updated dependency lists are also the ones that end up breaking by when you do update their dependencies. It only works in the simplest of patch versions.
Mixing multiple versions of the same (or closely related) libraries in the same program remains an issue even with self-contained applications. It might work out if the users of each version are isolated from each other, at the cost of program size and attack surface, but say you're using PyCrypto in one module and PyCryptodome in another, and you want to pass configuration or key information between them—the types won't match up. You'll also have two different API styles to deal with for the same tasks, which is bad for maintainability, which is ultimately bad for the user because it create more opportunities for bugs and makes it harder to implement new features and enhancements.