Por qué Scarf dejó Haskell tras 7 años

Scarf pasó 7 años en producción con Haskell antes de decidir moverse a otra base tecnológica. No fue una mudanza caprichosa ni un rechazo a la elegancia del lenguaje. Fue una decisión operativa, tomada después de convivir con costos reales: contratación, mantenimiento, tiempos de entrega, complejidad de tooling y una dependencia fuerte de perfiles muy específicos.

Ese caso sirve para algo más útil que repetir opiniones sobre lenguajes “bonitos” o “difíciles”: te obliga a mirar la ingeniería como un sistema completo. En producción no gana siempre el lenguaje más expresivo. Gana el que te deja entregar, operar, contratar, depurar y escalar con menos fricción total.

Qué pasó con Scarf y por qué importa

Scarf no abandonó Haskell por una sola falla técnica. Lo dejó después de años de experiencia acumulada, cuando la suma de pequeños costos empezó a pesar más que las ventajas iniciales. Ese matiz importa, porque muchas discusiones sobre lenguajes se quedan en el plano ideológico y no en el operacional.

La lección útil es esta: un stack puede ser excelente para arrancar un producto y, aun así, dejar de ser la mejor apuesta cuando el equipo crece, el sistema se vuelve más amplio o el negocio necesita velocidad de ejecución sostenida. Lo que sirve para una etapa no siempre sirve para la siguiente.

En el caso de Scarf, el punto no fue que Haskell “no funcione”. Funcionó durante 7 años. El punto fue que, con el tiempo, el costo marginal de seguir ahí empezó a superar el beneficio marginal. Esa es la clase de decisión que casi nunca se toma con un benchmark; se toma con experiencia acumulada.

El problema no es el lenguaje, es la carga total

Cuando eliges un lenguaje para producción, no estás eligiendo solo sintaxis. Estás eligiendo ecosistema, curva de contratación, tooling, disponibilidad de ejemplos, facilidad de onboarding, soporte en observabilidad y velocidad para responder incidentes.

Si tu equipo tarda 3 semanas en incorporar a una persona que ya sabe backend pero no Haskell, eso tiene costo. Si una incidencia tarda más en resolverse porque el conocimiento está concentrado en 2 personas, eso también tiene costo. Y si cada cambio pequeño requiere más revisión mental por la abstracción del código, el costo sube otra vez.

En otras palabras, la elegancia técnica no paga nómina por sí sola. El negocio paga por tiempo de entrega, resiliencia operativa y capacidad de contratar sin convertir cada vacante en una búsqueda artesanal.

Haskell en producción: ventajas reales y límites reales

Haskell tiene virtudes que no son humo. Su sistema de tipos puede eliminar categorías completas de errores antes de que lleguen a producción. Su enfoque funcional ayuda a escribir código más predecible. Y para ciertos equipos, esa disciplina reduce bugs y mejora el razonamiento sobre el sistema.

Pero esas ventajas vienen con una contrapartida. La productividad no depende solo de escribir menos errores. También depende de qué tan rápido puedes iterar con un equipo real, con rotación real y con deadlines reales. Ahí es donde Haskell puede dejar de ser la mejor opción para algunos productos.

No es raro que un stack muy sólido técnicamente tenga una comunidad más pequeña, menos oferta de talento y menos soluciones listas para problemas comunes. Eso no lo hace malo. Lo hace más costoso de operar cuando el contexto cambia.

Lo que Haskell sí te da

Hay beneficios concretos que explican por qué tantas empresas lo usan en partes críticas:

• Tipado fuerte y expresivo, que reduce errores en tiempo de compilación.
• Funciones puras, que hacen más fácil razonar sobre efectos.
• Código con alto nivel de abstracción, útil para sistemas complejos.
• Buen encaje para dominios donde la corrección pesa mucho.

Si tu caso de uso premia la precisión y tu equipo domina el lenguaje, puedes construir sistemas muy robustos. No hay que vender eso como un problema.

Lo que empieza a doler con el tiempo

El costo aparece cuando necesitas:

• Contratar rápido.
• Onboardear gente con experiencia en backend, pero no en Haskell.
• Mantener una base de código durante años con rotación de personal.
• Integrarte con herramientas y librerías más comunes en otros ecosistemas.
• Reducir el tiempo entre una idea y una entrega en producción.

Ahí el lenguaje deja de ser solo una ventaja técnica y se convierte en una decisión de estructura organizacional. Si tu empresa cambia, tu stack también tiene que poder absorber ese cambio.

Los costos operativos que pesan de verdad

Scarf no habría tomado una decisión así por una preferencia estética. La razón de fondo suele estar en costos que sí se sienten en el día a día. Hablemos de los más comunes, con foco en producción.

Primero está la contratación. Si tu lenguaje requiere experiencia específica y el mercado es pequeño, tu embudo de talento se achica. Eso alarga vacantes, sube el costo de búsqueda y aumenta la probabilidad de que el conocimiento quede concentrado en pocas personas.

Segundo está el mantenimiento. Un sistema no se mantiene solo con buenas intenciones. Hay upgrades, dependencias, cambios de infraestructura, incidentes y deuda técnica. Si cada una de esas tareas exige más contexto especializado, tu costo operativo sube.

Tercero está la velocidad de desarrollo. No solo importa cuántas líneas escribes, sino cuántas decisiones debes validar antes de cerrar un cambio. Un lenguaje muy expresivo puede ser poderoso, pero también puede elevar el costo cognitivo de cada modificación si el equipo no está perfectamente alineado.

Contratación y onboarding

En mercados como Latinoamérica, este punto pesa más de lo que muchas startups reconocen. Si quieres crecer en México, Colombia, Perú, Chile o Ecuador, necesitas un stack que no convierta cada contratación en una búsqueda de nicho.

No es que no haya talento Haskell en la región. Sí lo hay, pero suele ser más escaso que el de JavaScript, TypeScript, Python o Go. Si tu plan de crecimiento depende de sumar 4 o 5 personas en un año, ese diferencial importa mucho.

Además, el onboarding no es solo “leer documentación”. Una persona nueva necesita entender convenciones, patrones, tooling, tests, despliegues y debugging. Si el lenguaje ya es poco familiar, el costo de entrada sube otra vez.

Mantenimiento y respuesta a incidentes

En producción, la habilidad para responder rápido a un incidente vale tanto como la calidad del código. Si un bug aparece a las 2 a. m., te importa menos la elegancia del tipo y más cuánto tarda el equipo en localizar la causa y corregirla.

Un stack muy especializado puede hacer que la depuración dependa de pocas personas. Eso es frágil. Si además el conocimiento está distribuido de forma desigual, el riesgo operativo aumenta.

La decisión de Scarf sugiere que el equipo vio ese patrón con suficiente claridad como para cambiar de rumbo. No hace falta que el lenguaje falle técnicamente para que deje de ser la mejor opción operativa.

Cuándo un lenguaje elegante deja de ganar

Hay una idea incómoda pero útil: el lenguaje no se evalúa en abstracto, se evalúa contra tu contexto. Un stack puede ser excelente para un equipo pequeño, muy senior y con foco profundo en corrección, pero menos conveniente para una organización que necesita velocidad, rotación baja de riesgo y contratación amplia.

La pregunta correcta no es “¿este lenguaje es bueno?”. La pregunta es “¿este lenguaje sigue siendo la mejor combinación de costo, velocidad y confiabilidad para mi equipo ahora?”.

Ese cambio de pregunta evita discusiones religiosas. También ayuda a explicar por qué empresas serias migran después de años de éxito. No están corrigiendo un error de juventud. Están optimizando para una etapa distinta.

Señales de que ya cruzaste el umbral

Estas señales suelen aparecer antes de una migración:

1. El tiempo para contratar supera lo razonable para tu roadmap.
2. El onboarding tarda demasiado y depende de una o dos personas.
3. Los cambios pequeños requieren demasiada coordinación técnica.
4. El debugging se vuelve lento por la complejidad del stack.
5. El equipo siente que el lenguaje protege la base, pero frena la ejecución.

Si ves 3 o más de estas señales de manera sostenida, no estás ante una preferencia personal. Estás ante un problema de operación.

Una tabla simple para pensar el trade-off

La tabla no dice que Haskell sea malo. Dice que el balance cambia cuando el equipo y el negocio cambian.

Qué aprender si tú estás eligiendo stack hoy

Si estás evaluando un lenguaje para un producto nuevo, el caso de Scarf te deja una advertencia práctica: no optimices solo por la belleza del diseño. Optimiza por la capacidad de sostener el negocio durante varios años.

Eso no significa elegir siempre el lenguaje más popular. Significa mirar con honestidad el tamaño de tu mercado de talento, la madurez de tu equipo, el tipo de producto y la velocidad que necesitas para competir.

Si tu producto requiere mucha corrección formal, Haskell puede seguir siendo una gran opción. Si tu prioridad es crecer rápido con contratación amplia, probablemente quieras un stack con más disponibilidad de perfiles y más herramientas conocidas.

Tres preguntas que deberías hacer antes de decidir

1. ¿Cuántas personas con experiencia real en este stack puedo contratar en mi mercado objetivo en 90 días?
2. ¿Cuánto tardará una persona nueva en ser productiva sin depender de una sola guía interna?
3. ¿Qué pasa con mi velocidad de entrega si pierdo a la persona que más sabe del sistema?

Si no puedes responder estas preguntas con números o con una estimación razonable, tu decisión todavía está incompleta.

Ejemplo práctico para equipos en LatAm

Supón que tu empresa está creciendo desde Ecuador y abre vacantes remotas en la región. Si eliges un stack con talento más abundante, quizá encuentres 20 candidatos razonables por vacante. Si eliges uno muy especializado, tal vez encuentres 3 o 4, y no todos con experiencia en producción.

Eso no es un problema teórico. Se traduce en más tiempo de contratación, más presión sobre el equipo actual y más riesgo de retrasar entregas. En una startup, 2 meses perdidos en contratación pueden ser la diferencia entre llegar a un cliente o perderlo.

Por eso este caso importa más allá de Haskell. Te recuerda que el stack también es una decisión de mercado laboral.

Qué deja este caso para equipos técnicos y de producto

La salida de Scarf de Haskell después de 7 años no es una derrota ni una traición a la buena ingeniería. Es una señal de madurez. A veces el mejor movimiento no es defender una decisión antigua, sino revisar si sigue alineada con el presente.

Si trabajas en producto, te conviene leer esta historia como una advertencia contra la inercia. Si trabajas en ingeniería, te conviene leerla como una invitación a medir el costo total, no solo el mérito técnico. Y si lideras un equipo, te conviene usarla para revisar si tu stack actual facilita o dificulta contratar, operar y evolucionar.

La documentación oficial de Haskell sigue siendo un buen punto de partida si quieres entender mejor su modelo de tipos y su enfoque funcional: Haskell Language. Si comparas alternativas para backend, también vale revisar la documentación de Go, que suele aparecer en discusiones de contratación y operación: Go Documentation. Y si tu equipo vive en el mundo JavaScript o TypeScript, la documentación de TypeScript ayuda a entender por qué tantos equipos priorizan adopción amplia: TypeScript Handbook.

Tabla resumen