First thing that comes to mind is the need to link against libraries across platforms. Imagine that my app depends on opencv, if I wanted to statically link everything on my Windows machine, I need to compile opencv for Linux on my windows machine (or use pre-compiled binaries). Also, if you link against libraries dynamicaly, it's likely you can compile them on the host machine (or in a container) with more optimizations enabled. And the last thing is probably the ability to "freeze" the whole "system" environment (like folders, permissions, versions of system libraries).

Personally, I use containers to quickly spin-up different database servers for development or as an easy way of deployment to a cloud service...

Programmers discover the benefits of static linking, and then programmers discover the benefits of dynamic linking, and then programmers discover the benefits of static linking, and then...

Anyway containers go quite a bit further than just static linking, most people aren't out there linking all the binaries that their shell script uses together?

Well yes, but try turning some random python, java or ruby service into a single binary .. now do that 12 times. Or try with a native app that leverages both the GPU and libLLVM, and enjoy finding out the kind of precautions you have to take for LLVM to not blow up on a computer where your GPU driver was built with a different LLVM version.

That's exactly the summary of this.

That said, it makes sense from a developer POV; if, during development, you don't need the isolation you can run multiple containers (with on paper fast boot times and minimal overhead) on your development box.

There's plenty of cases to imagine where you need the containerization but not necessarily the isolation.

That what I do. I use https://github.com/jrz/container-shell so my projects are contained, and I'm a little bit protected against supply chain attacks

Why not use bubblelwrap or selinux or something? Docker is overkill for this.

Haven’t heard about bubblewrap, and I’m on my macOS. But I’ll look into it for inspiration

Because static libraries ain't a big thing anymore. Maybe they will become popular again. This would make it easier to have reproduceable build without a container. But I think containers are the new static libs now

Interpreted languages and their associated dependencies are more of an issue than static linking with compiled languages.

glibc doesn't work statically linked and lots of stuff depends on glibc

Yes, indeed, and that is golang's main reason for existing.

people would absolutely love to do that, but it's difficult, and the UX sucks

so people use containers instead (even if the container literally only contains a single statically linked binary)

What if you application is not just one binary. What if it's a pipeline of complex tasks, calls some python scripts, uses a patched version of some obscure library, ...

It's not possible to package half a Linux distribution into a single binary. That's why we have containers.