I don't think Docker is particularly reproducible. It has less understanding of dependencies than a Makefile. Not only does the cache rarely save build time,

I don't think Docker is particularly reproducible. It has less understanding of dependencies than a Makefile. Not only does the cache rarely save build time, it is also very unlikely that two developers running the same Dockerfile end up with the same bytes in their generated image. (The classic example is "FROM ubuntu:latest; RUN apt-get update && apt upgrade". No clue what's going to be in that image, it's different every time. You can pick a particular well-known build of the Linux base, but there is no lockfile that controls what apt upgrade is going to do. Even if you avoid that, esoterica like build tools that put the current time into binaries will bite you. Other build systems have a sandbox that lets you fake those tools out, so if your control file says the build time is 10 PM on Friday, then the next time you build it it's also 10 PM on Friday.) Docker also conflates too many concepts; layer generation, image distribution based on layers, registries and tags (mutable! wtf?), cgroups, PID namespaces, network namespaces, storage namespaces, etc. I'm sure it was a godsend for a certain type of workflow (one that depends heavily on the OS base; shelling out to utilities, using programming languages with poor dependency management systems, etc.) but for the average modern codebase, it seems like a detriment to me. I see people doing full builds of their app every time they want to test a change (often downloading 100s of packages from the Internet), simply because that's how Docker does things, and that honestly isn't right. They're throwing their time away for no good reason.