> Managing Python and Ruby is pretty easy until you hit a library with OS dependencies.
And that's why there is practically only one solution to solve it in either language (/sarcasm off).
Docker in my mind wasn't a sensible choice for compiled languages prior multi-stage builds, or better buildkit.
> Honestly that all seems to mostly derive from C/C++ issues, doesn't it?
It derives from having binary libraries, and a plethora of ABIs. And contrary to Go advocats and docker fans, I do believe they have their place. There is no perfect technical solution, there is always a trade-off.
With compiled languages you deliver binaries. A development / delivery split is expected.
The intermediate data (object files + debug data) often need a lot of storage, and are not supposed to be shipped directly. With a binary interface (ABI), you simply can ship your shared object or executable individually.
With statically linked/compiled binaries, you have to ship every binary using the fixed library. Or in case of docker, it will likely affect a lower layer which will invalidate all the upper layers of each docker image using said library.
So a couple of bytes delta in a couple of KB library can mean a couple of KB binary package, or a couple of multi-mb binaries or layers containing all the upper parts.
Your OS is most likely working with shared objects/DLLs and their ABIs, and there is a reason for that. Your use-case might not demand that, and that is okay, but it doesn't invalidate that there is a sensible reason for doing it the way it is done.
