I have a question here for Docker/container experts. Wouldn’t option 3 offer the advantage that the container runtime can cache the „Swift runtime library“ layer, such that when you deploy multiple apps on a node that all use the same container base image with the same Swift runtime libraries you should actually safe space and benefit from caching on the host/node? Whereas when every app statically links the runtime, you will potentially waste image space. So, I’m challenging a bit if we can really say that static linking is preferable for containerized deployments. I would have assumed containers are an excellent way to provide the runtime libs efficiently as a shared container layer.
yes, using docker containers can help users optimize for binary size. as mentioned in the proposal, the trade-off here is binary size vs. safety and convenience: when using a docker container as the provider of the runtime libraries you must match the exact compiler version you built with (eg if you built with 5.2.1 you must also use a docker container with the 5.2.1 runtime) and getting it wrong can lead to runtime issues which are usually unfortunate. the proposal makes the claim that we should pick the safer default (static inclusion of the runtime libraries), and those users that want to optimize for binary size could opt-out, vs. the other way around which is the default today.