Buscando información sobre Rails y Django, me he topado con un artículo que ilustra los puntos débiles del marco de desarrollo web de moda e introduce lo que podría ser el nuevo hype de la programación o, por fin, una alternativa a los grandes del sector: Rails, the 15 minutes is Almost Up. Meet Erlang.

Erlang es un lenguaje de alto nivel, funcional, de asignación única y dinámico, como Ruby. Ha sido desarrollado en los laboratorios de Ericsson partiendo de tres premisas fundamentales: tolerancia a fallos, concurrencia y sencillez. Las aplicaciones Erlang pueden correr sobre una máquina virtual o ser traducidas a código nativo gracias a un compilador de alto rendimiento llamado, irónicamente, HiPE.

A pesar de su origen, desde 1998 tanto la implementación del lenguaje como el conjunto de bibliotecas OTP son libres bajo la licencia EPL.

Total, que tenemos una plataforma peculiar cuya liberación cumple diez años. ¿Por qué es especial?

Pues por muchos motivos. Pero la expectación creada alrededor de Erlang tiene poco que ver con el lenguaje en si. Al fin y al cabo, hemos tenido una década para evaluarlo. Lo verdaderamente importante es el momento tecnológico que estamos viviendo. El paralelismo es ya el modelo indiscutible para alcanzar el máximo rendimiento, la guerra de los gigahertzios hace tiempo que terminó y la nueva guerra, la de los núcleos, está comenzando.

El soporte a la programación concurrente en los lenguajes tradicionales sigue siendo primitivo, muy propenso a errores. En este campo, Erlang es el rey. Puede crear y manejar cientos de miles de procesos sin despeinarse, incluso millones, evitándole al programador dolores de cabeza. El mismo lenguaje evita un montón de fallos gracias a la evaluación estricta o la asignación única de variables. Y si algo falla, ¡no hay problema! Erlang permite el cambio en caliente del código.

El lenguaje no viene solo. Trae bajo el brazo las ya mencionadas bibliotecas OTP (Open Telecom Platform), una metodología de programación (programación orientada a concurrencia), guías de diseño y patrones. Todo está probado y corriendo. De hecho, es muy probable que si realizas una llamada a través de tu teléfono móvil, alguno de los componentes que la harán posible esté construido sobre Erlang.

Más de uno se preguntará por qué coño no estamos todos alabando al dios Erlang y programando aplicaciones en este lenguaje como locos. Bueno, digamos que por muy bueno que sea, tiene algunas peculiaridades insalvables.

Para empezar, nos ha costado más de diez años adoptar el paradigma de objetos y no existe una disposición clara a cambiar de nuevo. Hemos pasado de los lenguajes estructurados a los orientados a objetos con sumo cuidado. Una muestra de ello es que C++ es casi una extensión de C y Java está inspirado en C++. ¿Y las metodologías? ¿Tendríamos que adaptar las herramientas de ingeniería de software?

Erlang da miedo porque no está respaldado por un paradigma y un lenguaje generalistas. Java llegó con la vitola de ser un C++ mejorado, lo cual demostró tener mucho peso en la comunidad de programadores. Era más sencillo, menos propenso a errores y tenía una extensísima biblioteca de clases. Sin embargo, ¿podríamos vender un Scheme mejorado? ¿Un Lisp mejorado? No es plausible. La industria está introduciendo lentamente los lenguajes funcionales como complemento de otros, como Linq, y las instituciones educativas ya les han hecho un hueco. A mí me enseñaron Caml, por ejemplo.

Y es que ya no estamos hablando de evolucionar desde un lenguaje estructurado a uno orientado a objetos. Este paso es mucho mayor. Hablamos de la enorme dificultad de cambiar los lenguajes procedimentales por lenguajes declarativos, lo que es paradójico pues un lenguaje declarativo debería tener una sintaxis más natural que uno procedimental.

Sí y no. Los que llevamos unos añitos en esto ya nos hemos adaptado a la máquina. Suena fuerte, ¿verdad? Modelamos en alto nivel y programamos en bajo nivel. Por muchas filigranas que tengan los lenguajes, por mucho que se haya escrito sobre esa facilidad a la hora de proyectar un objeto sobre algo del mundo real, todavía estamos obligados a pensar en qué queremos hacer y cómo queremos adaptar esa idea al modo de trabajar de la máquina.

Y resulta que los lenguajes funcionales no hacen eso. Intenta describir un proceso tradicional con funciones matemáticas y entenderás de qué hablo.

Pero no es tan complicado como parece. Las aplicaciones construidas con lenguajes funcionales suelen tener un código más limpio y elegante… Pero diferente. Y eso, claro está, es un hándicap.

Añadamos la orientación a concurrencia de Erlang y ya la hemos liado. Hay gente que se hace la picha un lío hasta que se da cuenta de que la primera A de Ajax es de asíncrono, ¡imaginaos qué ocurriría con una operación que cree dos docenas de procesos! Ojo, el lenguaje que nos ocupa hace que todo lo referente a la creación, destrucción, manejo y comunicación entre procesos sea insultantemente sencillo. Pero sigue siendo diferente.

Entonces, ¿a qué viene el título? ¿Por qué empezar poniendo los dientes largos a todo el mundo para caer en una aparente decepción? Bueno, Erlang tiene ahora mismo un nicho de mercado muy definido y casi intocable en aplicaciones destinadas a concurrencia o alta disponibilidad. Simplemente, es mejor que la competencia, así que podemos predecir una larga vida útil. Y si mañana alguien piensa que sería interesante incorporar al negocio un lenguaje que evite muchos de los errores de programación típicos y mejore la productividad y el rendimiento en los nuevos entornos multinúcleo, a costa de reciclarse en cuatro días, pues quién sabe, quizá lo que hoy es todavía una curiosidad alcance un buen lugar en el mercado.

Sea como fuere, estará ahí muchos, muchos años, tras el funcionamiento de tu teléfono, tu televisión o el último satélite lanzado al espacio.