Haskell: compilar código de 10 años sin cambios

Un compilador que tarda 6 horas en compilarse a sí mismo

El GHC, el compilador de referencia de Haskell, necesita 6 horas para completar su propia integración continua. El comité de liderazgo técnico de la Haskell Foundation quiere dejarlo en 2 horas, y acaba de anunciar que ya está operativo y trabajando en ese objetivo.

Para un founder, ese dato no es una curiosidad de ingeniería: el tiempo de build define cuántas veces al día tu equipo puede equivocarse, aprender y volver a intentar. Un ecosistema que tarda seis horas en decirte si un cambio rompió algo empuja a los equipos hacia ciclos de trabajo de días, no de minutos.

¿Qué es el comité técnico de la Haskell Foundation y qué puede decidir?

El comité se formó tras varias semanas de discusión interna sobre visión y estrategia. Su función no es solo opinar: va a desarrollar iniciativas y propuestas que considera que necesitan financiamiento y ejecución. Para eso busca empresas, contratistas y voluntarios.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El proceso de propuestas está diseñado para ser deliberadamente liviano. Pero con una condición explícita: cualquiera que escriba una propuesta debe saber que la comunidad tendrá espacio para comentarla y hasta presentar contrapropuestas. Donde hay dinero, hay escrutinio.

Eso convierte al comité en una pieza distinta a un grupo de trabajo habitual. Es una tubería para convertir ideas técnicas en proyectos financiados dentro de un ecosistema de código abierto. Y esa tubería, si funciona, es exactamente lo que un lenguaje maduro necesita para no depender de la heroicidad de sus voluntarios.

De 6 a 2 horas: el cuello de botella está en el ciclo de feedback

La visión describe el problema con precisión. Los flujos de trabajo modernos exigen iteración rápida: compilación, repl interactivo, caché de dependencias remotas, integración con CI y con tests. Todo eso afecta tanto al trabajo humano como al de las máquinas.

La frase clave del documento es incómoda y honesta: Haskell escala bien en complejidad de código, pero no escala bien en tiempos de build.

No es un diagnóstico nuevo, y el trabajo ya empezó. Según la página de proyectos de la Haskell Foundation, Bryan Richter trabaja a tiempo completo para la fundación mejorando la implementación de CI de GHC, con foco en confiabilidad y observabilidad. Además, la fundación coordinó la disponibilidad de builds nocturnos de la versión de desarrollo de GHC dentro de GHCUp, para que cualquier proyecto pueda programar un job de CI que verifique si los cambios del compilador siguen siendo compatibles con su código.

Esa mecánica de detectar incompatibilidades antes, y no después, es la diferencia entre un upgrade de fin de semana y tres sprints perdidos.

¿Por qué Haskell se ofrece como el lenguaje del humano en el bucle de la IA?

Aquí hay una tesis que vale la pena leer con atención. El comité sostiene que la revisión es un cuello de botella central en los flujos de trabajo con IA, y que las fortalezas de Haskell favorecen al revisor: seguridad de tipos, abstracciones potentes y transparencia referencial.

A eso suma la capacidad de diseñar eDSLs rápido y expresar restricciones donde importan, lo que permite armar guardrails fuertes para la generación de código sin perder flexibilidad. Su formulación es directa: puede haber mejores lenguajes para verificación formal o para vibecoding, pero no para mantener el humano en el bucle.

La implicación práctica para una startup que ya genera código con modelos es concreta. Si tu cuello de botella dejó de ser escribir y pasó a ser revisar, el valor de un lenguaje está en cuánto puede restringir lo que la máquina produce antes de que llegue a producción. Tipos estrictos y restricciones expresables son una capa de revisión que trabaja mientras duermes.

La promesa más difícil: compilar código de 10 años sin tocar una línea

La meta declarada es ambiciosa hasta el borde de lo imposible: que se pueda compilar software Haskell de 10 años de antigüedad con el GHC más reciente, sin cambios en el código fuente. El propio comité admite que el objetivo puede no alcanzarse, pero sostiene que el camino ya deja un ecosistema más robusto y predecible.

Las preguntas que enumeran son las que cualquier founder con deuda técnica se hace: cómo optar por no recibir cambios que rompen, cuánto tiempo se mantienen abiertas las ventanas de soporte y cómo mejorar la experiencia de upgrade.

Y no es solo discurso. La página de proyectos de la fundación documenta un Stability Working Group que trabaja en una clasificación simple de las extensiones del lenguaje, para que los equipos puedan decidir con información el trade-off entre estabilidad e innovación y ver esa política reflejada en los warnings del compilador. La fundación también lidera el desarrollo de una API estable de GHC, facilitando la conversación entre quienes construyen herramientas y quienes mantienen el compilador, y está en proceso de hacerse cargo del hosting de Stackage.

Seguridad, onboarding y los frentes que no dan titulares

El documento promete el tiempo de respuesta a incidentes más rápido entre los ecosistemas de lenguajes, pruebas de penetración regulares a su infraestructura, aviso claro de vulnerabilidades y mitigaciones, una biblioteca criptográfica robusta y una cadena de suministro endurecida.

Parte de eso ya tiene forma de proyecto. La fundación mantiene la Haskell Security Advisory Database a través de su Security Response Team, y la exporta a OSV, el estándar de la industria para herramientas multi-lenguaje. También existe el proyecto de bindings de Botan, orientado a darle al ecosistema capacidades criptográficas auditadas.

En onboarding, la apuesta es explícita: instalación tan rápida que dudes si funcionó, documentación que no te deje trabado y herramientas que no te obliguen a pedir soporte. La fundación ya organizó, junto a la OST Eastern Switzerland University of Applied Sciences y los desarrolladores de GHC, una introducción práctica de tres días con 43 participantes presenciales, nueve expositores del proyecto GHC y seis voluntarios adicionales.

¿Qué significa esto para tu startup?

Si ya usas Haskell en producción: no esperes pasivo al plan de estabilidad. Fija tu versión de GHC, agrega un job de CI programado contra los builds nocturnos que la fundación publica en GHCUp y entérate de las incompatibilidades en el ciclo donde todavía son baratas.
Si estás evaluando el lenguaje: el argumento cambió de lugar. Ya no es solo corrección formal; es capacidad de revisar código generado por IA con reglas que el compilador hace cumplir.
Si eres empresa o proveedor: el comité busca explícitamente compañías, contratistas y voluntarios. Y como el proceso abre comentarios y contrapropuestas de la comunidad, entrar temprano te da influencia real sobre cómo se asignan los recursos.
Si tu equipo revisa código generado por máquinas: trata los tipos y las restricciones como parte del pipeline de revisión, no como una formalidad académica. Es la forma más barata de reducir lo que llega a un revisor humano.

Conclusión

La Haskell Foundation no anunció montos, plazos de financiamiento ni un calendario de entrega para estas iniciativas; el comunicado describe visión, prioridades y un mecanismo de propuestas. Es decir, un plan de intenciones con un proceso concreto detrás.

Aun así, el diagnóstico es el que importa y aplica a cualquier stack: los lenguajes con grandes garantías suelen pagar esas garantías con velocidad de iteración. Quien resuelva ese intercambio, gana. Y el objetivo de bajar el CI de GHC de 6 a 2 horas es una forma medible de comprobarlo.