Después de 7 años en producción, Scarf se ha alejado a regañadientes de Haskell
Papel de los tipos con los LLM
- Muchos sostienen que los tipos estáticos fuertes son más valiosos con los LLM, porque detectan resultados “basura” y hacen que el código generado por IA sea más fácil de entender y refactorizar.
- Otros destacan que los LLM a menudo evitan o corrigen rápidamente por sí mismos errores simples, así que el beneficio marginal de sistemas de tipos muy fuertes puede ser menor que antes.
- Hay desacuerdo sobre si los LLM reducen la necesidad de seguridad de tipos o la vuelven más crítica; varios comentaristas dicen explícitamente que la conclusión de “menos seguridad de tipos” les resulta desconcertante.
Tiempos de compilación y flujos de trabajo con agentes
- La queja central: los lentos tiempos de compilación en frío de Haskell se convierten en un cuello de botella severo para flujos de trabajo agénticos que compilan y ejecutan pruebas con frecuencia, especialmente en varios worktrees/agentes.
- Algunos responden que menos comprobaciones del compilador, pero más ricas, pueden compensar compilaciones lentas, aunque reconocen que un coste base de 15 minutos es difícil de amortizar.
- Varios señalan que este problema ya perjudicaba la productividad humana; los LLM solo lo hacen más visible. Otros sugieren mejor caché de compilación/infraestructura como alternativa a reescribir.
Python frente a otras opciones de lenguaje
- A muchos les sorprende que el cambio sea a Python en lugar de TypeScript, Go, OCaml, Rust, Java, C#, F#, etc., que ofrecen tipado más fuerte con tiempos de compilación decentes.
- Defensas de Python: familiaridad del equipo, enorme ecosistema, abundancia de datos de entrenamiento para los modelos y ausencia de paso de compilación.
- Críticas: ecosistema de tipado débil y fragmentado, necesidad de varias herramientas de tipos, anotaciones inconsistentes en las bibliotecas, numerosos “footguns” para servidores y peor rendimiento en tiempo de ejecución.
Experiencias con Haskell y alternativas
- Algunos informan de flujos de trabajo muy productivos con Haskell+LLM y no ven el tiempo de compilación como un problema importante en la práctica.
- Otros ya han dejado Haskell (por ejemplo, por Rust) debido a la pereza, las excepciones, el tamaño/fragmentación del ecosistema y los problemas de herramientas.
- OCaml, Lean, F#, Go y los lenguajes de la JVM se citan repetidamente como posibles puntos intermedios prometedores: compilaciones rápidas más tipos útiles.
Reflexiones más amplias sobre la era de la IA
- Debate sobre si nos estamos moviendo hacia un mundo “post-lenguaje” en el que los agentes impulsen la elección del lenguaje por eficiencia (runtime, coste de tokens, tiempo de pared).
- Preocupación de que optimizar la velocidad del “vibecoding” pueda erosionar el rigor de ingeniería y la mantenibilidad a largo plazo.
- Algunos sostienen que los futuros lenguajes deben elegir: diseñarse principalmente para humanos o para agentes; estos objetivos pueden entrar en conflicto.