It depends on the problem. Someone could say that static linking optimizes for runtime costs but for the problems that OP (and me) are trying to solve, I find t

It depends on the problem. Someone could say that static linking optimizes for runtime costs but for the problems that OP (and me) are trying to solve, I find that it increases runtime complexity since: + It tightly couples independent subsystems together, you can no longer see them (e.g. update) in isolation. Some of those subsystems explode when statically linked due to second-order effects (e.g. memory management). + Requires compilation. + Licensing woes that do not apply with dynamic linking. + Most important: Static linking reduces your runtime flexibility by being the opposite of late-binding and forces you to commit upfront. Many problems can be elegantly solved when one can take additional context into account (e.g. delay solving them until the 'how' becomes clear). On top of that, static linking does not optimize for deployment costs, which can be substantial depending on the application and frequency of component changes. For all these reasons, it should be avoided when possible. The counterpoint is that in practice, it takes a lot more effort to design a system that does not deploy static linking in order to solve the problems described by OP and me. Static linking is thus an easy and quick solution but it comes with many strings attached.