mise, Nix y devcontainers resuelven todos el problema «funciona en mi máquina» — solo discrepan en el cómo

La frase «funciona en mi máquina» ha perseguido a los equipos de software durante décadas. Un nuevo miembro se une, dedica dos días a configurar su entorno. Un desarrollador senior actualiza Python, rompe tres proyectos. CI falla por una versión de biblioteca que nadie recordaba haber fijado. La causa raíz siempre es la misma: los entornos de desarrollo son con estado, implícitos y ensamblados manualmente.

En 2026, este problema está genuinamente resuelto — pero «resuelto» significa tres herramientas competidoras con filosofías radicalmente diferentes. Comprender las compensaciones es la habilidad real.

Nivel 1 — mise: El punto de partida pragmático

mise (anteriormente rtx) es un gestor de versiones multilingüe escrito en Rust. Reemplaza a asdf funcionando entre 10 y 20 veces más rápido gracias a su núcleo compilado y resolución paralela de complementos. Maneja Node.js, Python, Go, Ruby, Java y docenas de otros entornos de ejecución desde una sola herramienta.

El mecanismo principal es .mise.toml en la raíz del proyecto:

[tools]
node = "22.3.0"
python = "3.12.4"
go = "1.22.5"

[env]
DATABASE_URL = "postgres://localhost/myapp_dev"

Ejecuta mise install y lee la configuración, descarga las versiones fijadas en una caché local direccionada por contenido (~/.local/share/mise/installs/) y las activa para el directorio actual. Sin manipulación de enlaces simbólicos, sin trucos de shell más allá de agregar mise activate a tu perfil.

La diferencia de rendimiento respecto a asdf no es sutil. Instalar una versión de Node.js que a asdf le toma 45 segundos resolver e instalar, mise lo completa en menos de 4 segundos. Para equipos que cambian constantemente entre proyectos con diferentes requisitos de entorno de ejecución, esto se traduce en ahorros de tiempo reales.

Lo que mise no hace: gestiona entornos de ejecución de lenguajes, no bibliotecas del sistema. Si tu proyecto necesita una versión específica de libpq, openssl o ffmpeg, mise no puede ayudar. Tampoco puede reproducir la versión exacta de glibc en Linux ni la cadena de herramientas exacta de Xcode en macOS. Para la mayoría de los desarrolladores de aplicaciones, estas brechas no importan. Para todos los demás, sigan leyendo.

Nivel 2 — Nix y Nix Flakes: Reproducibilidad total

Nix es un gestor de paquetes funcional construido en torno a una idea: cada paquete es una función pura de sus entradas. Dadas las mismas entradas, siempre obtienes la misma salida. Los paquetes residen en /nix/store/ bajo rutas direccionadas por contenido como /nix/store/ybmrfz0-nodejs-22.3.0/. Dos paquetes pueden depender de diferentes versiones de la misma biblioteca sin conflicto porque literalmente viven en rutas diferentes.

nixpkgs es el repositorio de paquetes: más de 90,000 paquetes, todos construidos de forma reproducible, abarcando todos los principales ecosistemas de lenguajes además de herramientas del sistema, fuentes, bases de datos y compiladores. Es el conjunto de paquetes de fuente única más grande de cualquier distribución de Linux.

Nix flakes (estabilizado en NixOS 23.11) agrega un modelo de dependencias impulsado por lockfile al propio Nix. Un archivo flake.nix en la raíz del proyecto fija el commit exacto de nixpkgs y define un devShell:

{
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.05";

  outputs = { self, nixpkgs }: {
    devShells.x86_64-linux.default = nixpkgs.legacyPackages.x86_64-linux.mkShell {
      packages = with nixpkgs.legacyPackages.x86_64-linux; [
        nodejs_22
        python312
        go_1_22
        postgresql_16
        ffmpeg
      ];
    };
  };
}

Ejecuta nix develop y entras en un shell donde cada herramienta está exactamente como se especifica — hasta las versiones de la biblioteca C. El archivo flake.lock fija el SHA del commit de nixpkgs. Seis meses después, en una máquina diferente, en un país diferente, nix develop produce el mismo entorno.

La curva de aprendizaje honesta: Nix tiene su propio lenguaje funcional (también llamado Nix), su propio modelo mental de cómo funcionan las compilaciones y documentación que asume familiaridad con conceptos de programación funcional. La mayoría de los desarrolladores tardan entre 1 y 2 semanas en sentirse cómodos escribiendo flakes desde cero. Herramientas como devenv.sh y flake-parts reducen esto significativamente, pero no hay atajo para los conceptos fundamentales.

La recompensa es real. Los equipos que usan Nix flakes reportan cero problemas de «deriva del entorno» en las revisiones post-mortem. CI ejecuta el mismo shell nix develop que el desarrollo local. Los nuevos miembros ejecutan nix develop el primer día y tienen un entorno funcional en minutos, no en días.

Nivel 3 — devcontainers: Incorporación y desarrollo cloud-first

devcontainers es una especificación abierta (respaldada por Microsoft y utilizada en VS Code y GitHub Codespaces) que define un entorno de desarrollo como un contenedor Docker. La configuración reside en .devcontainer/devcontainer.json:

{
  "name": "My Project",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "features": {
    "ghcr.io/devcontainers/features/python:1": { "version": "3.12" },
    "ghcr.io/devcontainers/features/go:1": { "version": "1.22" }
  },
  "postCreateCommand": "npm install",
  "customizations": {
    "vscode": {
      "extensions": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
    }
  }
}

La extensión Remote - Containers de VS Code monta tus archivos locales en el contenedor y ejecuta todo tu editor dentro de él: servidores de lenguaje, depuradores, terminales, todo ejecutándose en el entorno del contenedor. GitHub Codespaces lleva esto más allá: haz clic en «Open in Codespaces» y todo el entorno de desarrollo se ejecuta en la infraestructura en la nube de GitHub, no en tu portátil.

Dónde ganan los devcontainers: la incorporación es genuinamente de un solo clic. El aislamiento de seguridad es real: el sistema de archivos del contenedor está separado del anfitrión. Para tareas computacionalmente intensivas (entrenamiento de modelos grandes, renderizado de video, compilación de grandes bases de código C++), descargar a Codespaces con máquinas en la nube de 32 núcleos es productividad legítima.

Dónde luchan los devcontainers: la sobrecarga de Docker es real en macOS. El rendimiento del sistema de archivos a través de la capa VM de Docker puede ser de 2 a 3 veces más lento que el nativo para tareas intensivas en E/S, como ejecutar un gran conjunto de pruebas. También dependes de la conectividad de red y de que Docker esté operativo — ninguna de las dos está garantizada en todos los contextos de desarrollo.

Cómo combinan estas herramientas los equipos reales

La elección falsa es elegir una e ir a por todas. Los equipos que han descubierto esto suelen estratificar:

• mise para el cambio de lenguaje día a día. Todos los desarrolladores lo tienen. Maneja el 90% de las preguntas «qué versión de Node/Python/Go» con mínima fricción. El .mise.toml se sube al repositorio.
• Nix flakes para equipos con requisitos a nivel de sistema. Si necesitas versiones específicas de bibliotecas nativas, o si construyes tanto en Linux como en macOS y necesitas entornos idénticos, flake.nix vale la inversión. Algunos equipos usan Nix solo para CI, obteniendo reproducibilidad donde más importa.
• devcontainers para la incorporación y paridad con CI. La configuración .devcontainer/ se mantiene para el día uno de los nuevos miembros y para el acceso a GitHub Codespaces. No reemplaza las herramientas de desarrollo local, pero proporciona un respaldo garantizado.

Un ejemplo concreto: un equipo de 12 desarrolladores usa mise localmente para el cambio rápido de versiones, Nix flakes en CI (GitHub Actions ejecuta nix develop --command make test) y un devcontainer para el acceso a Codespaces cuando los miembros del equipo viajan o están en máquinas corporativas restringidas.

Las compensaciones honestas

• mise: se instala en 30 segundos, funciona en todas partes, maneja el 90% de los problemas reales, pero no puede gestionar bibliotecas del sistema ni garantizar la reproducibilidad binaria por debajo del nivel del entorno de ejecución del lenguaje.
• Nix: la opción más potente disponible, produce entornos genuinamente reproducibles bit a bit, cubre todas las capas de la pila, pero requiere una inversión real para aprender y puede hacer que tareas simples (añadir una dependencia de un nuevo paquete) parezcan pesadas hasta que los conceptos encajen.
• devcontainers: la barrera de entrada más baja para la incorporación, nativo en la nube, nativo de VS Code, pero conlleva la sobrecarga de Docker, requiere conectividad y puede ocultar detalles del entorno de maneras que dificultan la depuración.

Por dónde empezar

Si tu equipo tiene menos de 5 desarrolladores y el problema es «cada uno tiene diferentes versiones de Node/Python»: instala mise hoy, sube un .mise.toml, listo. Solucionarás el 90% de las quejas del entorno en una tarde.

Si tu equipo tiene 10 o más desarrolladores, estás entregando en Linux, tienes dependencias de bibliotecas nativas y la deriva del entorno ha causado incidentes de producción reales: invierte en Nix flakes. Presupuesta de 2 a 3 semanas para que un desarrollador se convierta en el experto en Nix del equipo. El retorno es genuino.

Si tu principal dolor es el tiempo de incorporación, trabajas intensamente con GitHub o necesitas aislamiento seguro para contratistas: los devcontainers son la palanca adecuada. Se combinan bien tanto con mise como con Nix: puedes ejecutar mise dentro de un devcontainer o construir tu imagen de devcontainer a partir de una derivación de Nix.

El problema «funciona en mi máquina» está resuelto. La pregunta restante es qué solución se ajusta a las restricciones reales de tu equipo — y si estás dispuesto a pagar los costes de aprendizaje que requieren las opciones más potentes.