I understand that and don't really disagree with any of it, but what I'd say I'd say is that there's a third possibility of doing what containers already do --

I understand that and don't really disagree with any of it, but what I'd say I'd say is that there's a third possibility of doing what containers already do -- use dynamic linking against fixed versions you control. That is, the way I think of it is more along the lines of whether an executable is a "value" (in the Hickey sense), not whether it's statically linked. So the whole container can be a value, but it's not statically ed linked. That has bearing on both incremental builds and distribution. This relates to my comments on the article about size optimization: https://lobste.rs/s/rbdgr2/size_optimization_tricks#c_x6lz53 https://lobste.rs/s/rbdgr2/size_optimization_tricks#c_x6lz53 i.e. I think it makes sense for executables to retain structure for differential compression (they can be a tree, not a flat file.) --- Also I'm wondering if the sandboxing can be done in a child process, without the cooperation of the build tool. I don't see why not, but I'll have to try it (and especially with the container model, which changes things a bit). That could actually make the dynamic library issue easier to deploy because you've punted some policy (hard-coded paths) into a separate tool, rather than having it in the build tool.