Nix es un mejor constructor de imágenes Docker que el constructor de imágenes de Docker

Nix vs. Docker como constructores de imágenes

• A las compilaciones basadas en Nix se las elogia por la gestión de dependencias declarativa y de grano fino, y por una reproducibilidad más estricta que la de los Dockerfiles típicos.
• Se critica a los Dockerfiles por una no determinación imperceptible (tags flotantes, apt-get sin fijar versiones, git clone de ramas), aunque algunos sostienen que un uso disciplinado de digests, snapshots y mirrors también puede hacer reproducible a Docker.
• Varios señalan que el modelo de capas de Docker es jerárquico y está orientado a pasos de compilación imperativos, mientras que Nix mapea un grafo de dependencias a capas, lo que permite capas más reutilizables y direccionadas por contenido.

Capas, snapshotters y herramientas

• El límite de 128 capas de Docker es un problema real al mapear ingenuamente las rutas del almacén de Nix a capas; la gente usa heurísticas o agrupamientos, lo que perjudica la reutilización de la caché.
• nix-snapshotter integra Nix con containerd: los contenedores se montan directamente desde el almacén de Nix; docker pull se convierte en sustitución de Nix, evitando la duplicación de tarballs y el límite de capas. El despliegue es sencillo en clústeres basados en containerd, pero más difícil en k8s gestionado.
• nix2container y buildLayeredImage de Nix mejoran la caché y las subidas al registry mediante la transmisión de capas y su almacenamiento en la caché de Nix, además de permitir que los usuarios elijan explícitamente qué va en cada capa.

Tamaño de imagen y optimización

• Algunos informan que las imágenes construidas con Nix son inesperadamente grandes (por ejemplo, grandes imágenes base de Nix, JDK completos, glibc con todos los locales).
• Otros muestran que, con un uso cuidadoso de musl, JREs headless, JREs mínimos y overrides para eliminar funciones no usadas, las imágenes Nix pueden ser competitivas o pequeñas; buildLayeredImage permite compartir grandes dependencias (glibc, JDK) entre muchas imágenes.

Experiencia de desarrollo y complejidad

• Hay una fuerte división: los entusiastas valoran que un solo flake pueda describir compilaciones, shells de desarrollo, imágenes Docker, módulos de NixOS y tests; los escépticos encuentran que flakes y el lenguaje de Nix son difíciles de aprender, están demasiado abstraídos y están mal documentados.
• Quejas comunes: errores opacos, “rincones oscuros”, una curva de aprendizaje pronunciada para la compilación cruzada y arquitecturas de flakes grandes y personalizadas que abruman a los recién llegados.
• Se mencionan varios intentos de domar la complejidad (patrones de estructuración de flakes, frameworks de nivel superior, herramientas como flox), pero el consenso es que la DX sigue siendo una barrera importante.

Preocupaciones multiplataforma y del ecosistema

• Los usuarios de macOS/darwin se enfrentan a compilación cruzada lenta o frágil, cachés de Hydra ausentes e integración complicada con Docker; muchos recurren a builders remotos o a máquinas virtuales Linux.
• Se cita Guix como una alternativa funcional similar con guix pack -f docker, pero sufre actualizaciones de paquetes más lentas y retrasos de revisión.
• Para casos de uso sencillos (por ejemplo, servicios Go/Java), algunos argumentan que los constructores de imágenes específicos del lenguaje (ko, Jib, reglas rules_oci de Bazel) son preferibles a la complejidad de Nix.