7 años en Haskell, 1 decisión: lo abandonaron todo por Python — y la culpa la tiene la IA

Scarf llevaba 7 años corriendo Haskell en producción. Tenían SLAs contractuales, uptime garantizado, y un equipo que conocía cada esquina oscura del lenguaje. Y lo dejaron por Python. No porque Haskell fallara, sino porque la IA cambió completamente las matemáticas del desarrollo.

Avi Press, fundador de Scarf y miembro del board de la Haskell Foundation, publicó un post que está sacudiendo a la comunidad dev: después de más de una década usando Haskell — construyendo APIs con Servant, bases de datos con Beam, y servicios de alto rendimiento directamente sobre WAI — la empresa decidió migrar todo a Python.

Y la razón no es la que esperas.

El problema no era Haskell — era el compilador

Press lo dice clarísimo: el código Haskell era confiable. El sistema de tipos atrapaba bugs reales. El lenguaje los forzaba a modelar su dominio con cuidado. El rendimiento era excelente. El problema era cuánto tiempo perdían esperando a que todo compilara.

Cuando un humano escribía código durante una hora, esperar 20 minutos a que el compilador terminara era molesto pero tolerable. Pero entonces llegaron los agentes de código con IA, y todo cambió.

Un LLM genera un cambio en minutos. Si tu compilador tarda 15 minutos en una build fría, el compilador pasó de ser una molestia a ser el cuello de botella dominante del desarrollo.

La IA multiplicó el problema por 5

El siguiente paso fue lo que rompió el vaso: Press quería ejecutar múltiples agentes de IA en paralelo. Cinco worktrees, cinco ramas, cinco líneas de trabajo diferentes explorando cambios simultáneamente.

En ese escenario, cada nuevo worktree cobra un impuesto de compilación. Si cada ramita necesita una build fría de Haskell, o necesita configuración cuidadosa de caché, o quema una montaña de memoria, ese impuesto se multiplica exponencialmente.

La gente de Haskell habla de Nix, de caché, de builders remotos. Press los usó todos. Pero el caché nunca es perfecto, y la cantidad de esfuerzo requerida para hacer que el caché funcione "suficientemente bien" es parte del problema.

La métrica que importa ahora

Press propone una métrica que ningún lenguaje tiene en su portada: cuánto tiempo dura tu ciclo completo de retroalimentación de desarrollo, y qué porcentaje de ese tiempo lo pasas esperando al compilador.

Si el best case es 20 segundos (todo cacheado, cambio pequeño), eso suena genial. Pero el best case no es lo que puedes usar para optimizar todo el sistema. Los cambios profundos en el core del build plan, los cold starts, los promedios reales — ahí es donde Haskell se convierte en un ancla.

Y aquí viene el dato que duele: cada nuevo estilo de trabajo (agentes en paralelo, forks rápidos, worktrees descartables) necesita contextos de ejecución baratos y descartables. El entorno de Haskell de Scarf simplemente no era lo suficientemente barato para ese estilo.

La solución: Python con migración gradual

En vez de un Big Bang, Scarf implementó una migración elegante: levantaron un servidor Python al lado del Haskell, enrutaron tráfico, y empezaron a mover funcionalidad pieza por pieza.

Nuevas rutas API van a Python. Código Haskell existente sigue corriendo. Con el tiempo, el servidor nuevo se convierte en el path principal y el footprint de Haskell se encoge.

Lo más irónico: reimplementar autenticación, acceso a base de datos, modelos compartidos y tests — trabajo que antes parecía carísimo — con los LLMs actuales fue bastante sencillo. Portar código existente a un nuevo lenguaje es exactamente lo que los modelos hacen bien.

¿Qué significa esto para ti como dev?

Este no es un "Haskell es malo" — Press lo deja claro desde el principio. Es un "las reglas cambiaron." Los lenguajes con compiladores lentos están perdiendo una ventaja silenciosa: su costo real de desarrollo subió porque la velocidad de generación de código subió, pero la velocidad de verificación se quedó igual.

Si usas Rust, Go, o C++ en producción, la pregunta que deberías hacerte es: ¿cuánto de tu tiempo de desarrollo lo pasas esperando a que compile? Y más importante: cuando empieces a usar agentes de IA para generar código en paralelo, ¿ese número va a explotar?

Los lenguajes con compilación instantánea (Go, Python, JavaScript) no tenían prestigio en el mundo enterprise. Pero ahora que la IA genera código más rápido de lo que lo escribe un humano, la velocidad del compilador se convirtió en un superpoder competitivo.

El futuro es descartable

El estilo de trabajo que Press describe — forks rápidos, agentes explorando ramas, descartar lo que no funcione — es el futuro de la programación. Y ese futuro necesita lenguajes baratos de ejecutar, baratos de iterar, y baratos de descartar.

Haskell fue durante 16 años el lenguaje más importante de la vida de Press. Lo recomendó, construyó una empresa sobre él, sirvió en la fundación. Y lo dejó porque el mundo cambió más rápido que el lenguaje.

La pregunta no es "¿es Haskell un buen lenguaje?" — es "¿es un buen lenguaje para un mundo donde una IA escribe el código en 3 minutos y tú solo necesitas verificar que funciona?"

La respuesta, tristemente, ya la dio Scarf.

💬 ¿Ves a tu lenguaje favorito en esta misma encrucijada? Si usas Rust, Zig, o cualquier lenguaje con compilación lenta, ¿cuánto tiempo pierdes esperando a que compile? Cuéntame en los comentarios.

Comparte esto si crees que los lenguajes de programación necesitan dejar de vivir en el pasado 🔄