Erlang prevalecerá

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.

Explore posts in the same categories: General, Programación

Tags: , , , , , ,

You can comment below, or link to this permanent URL from your own site.

4 Comments on “Erlang prevalecerá”

  1. kabish Says:

    Muy interesante, sobre todo teniendo en cuenta que el gran pero de Ruby es el tratamiento de los hilos. Pero creo que hasta ahora el software de supercomputadores y orientado especialmente a tratar procesos concurrentes se sigue manejando con librerías específicas, tipo PVM etc., Por eso los 10 años que lleva existiendo Erlang no han sido tantos para evaluarlos. Ahora es cuando llega el desafío de programar software popular pensando a lo grande, tolerancia a fallos, miles de procesos paralelos, etc.

  2. Juan Lupión Says:

    Buena anotación. A primeros de años me compré el libro de los Pragmatic Programmers sobre Erlang, escrito por el propio autor del lenguaje, y destacaría dos cosas: que Armstrong tiene una sintaxis espantosa (por si el salto de paradigma fuese poco) y que Joe Armstrong es bastante malo como divulgador (a fin de cuentas la primera documentación sobre un lenguaje es la que escribe su creador) Personalmente creo que estos dos peros convierten a Erlang en un lenguaje de nicho. (Igual me equivoco)

    Lo que no quiere decir que sus fundamentos no sean interesantes. El lenguaje Scala, por ejemplo, parece un intento de hacer lo mismo sobre la JVM, con una sintaxis similar a Ruby y con una semántica de paso de mensajes como en Erlang.

  3. qbit Says:

    Lenguajes concurrentes los hay desde la época de Ada por lo menos. Si no tienen más auge es porque no hacen falta, porque los problemas concurrentes se han abordado y solucionado de otras maneras más eficientes. ¿O es que un ordenador con su sistema operativo no es algo concurrente, produciéndose interrupciones continuamente e interacciones ente procesos?.

    No hay beneficios claros en su uso, y además, cuanto más alto nivel, más ineficacia para la máquina. Mucha gente aborrece Java por lo ineficaz que es, sin ir más lejos.

  4. manuelabeledo Says:

    Léete mejor el artículo, anda :)

Comment: