La esencia de Erlang no trata sobre procesos livianos ni paso de mensajes (2023)

Contexto

• Erlang es un lenguaje desarrollado para construir sistemas distribuidos confiables; comenzó como una biblioteca de Prolog y evolucionó hasta convertirse en un lenguaje independiente.
• Se usó en Ericsson para programar centrales telefónicas y, en 1998, pasó a ser de código abierto.
• Joe Armstrong fue uno de los principales diseñadores de Erlang, y su tesis doctoral trata sobre cómo crear sistemas distribuidos confiables en presencia de errores de software.

Comportamientos (Behaviours)

• Los comportamientos de Erlang son similares a las interfaces de Java o Go, y consisten en un conjunto de firmas de tipos que pueden tener varias implementaciones.
• Los comportamientos permiten escribir solo el código que define la lógica de negocio del programa, mientras que el código de infraestructura se proporciona automáticamente.
• Los comportamientos son escritos por expertos y se basan en las mejores prácticas.

Comportamiento de servidor genérico

• gen_server se explica con un ejemplo de implementación de un almacén clave-valor.
• handle_call se encarga de actualizar el estado o consultar una clave, y toda la concurrencia queda oculta dentro del componente gen_server.

Comportamiento de administrador de eventos

• gen_event es un administrador de eventos que registra manejadores de eventos y los ejecuta cuando llega un mensaje.
• Es útil para el registro de errores, y se ofrece un ejemplo sencillo de logger.

Comportamiento de máquina de estados

• gen_fsm fue renombrado a gen_statem y es adecuado para implementar protocolos.

Comportamiento de supervisor

• Un supervisor verifica que otros procesos funcionen correctamente y, si fallan, los reinicia según una estrategia predefinida.
• La estrategia one_for_one reinicia solo el proceso que falló, mientras que la estrategia one_for_all reinicia a todos los hijos cuando falla uno de los procesos.

Comportamientos de aplicación y release

• Una aplicación incluye el árbol de supervisión y todo lo necesario, mientras que un release empaqueta una o más aplicaciones.
• Debe ser posible hacer rollback si una actualización falla.

Implementación de comportamientos

• Más que los procesos livianos y el paso de mensajes de Erlang, es la estructura de los comportamientos lo que conduce a software confiable.
• Para implementar comportamientos en otros lenguajes, se puede empezar usando firmas de interfaces.

Corrección de los comportamientos

• Las pruebas de simulación facilitan el testeo de sistemas distribuidos, y la estructura del comportamiento gen_server puede usarse para simplificar la resolución de problemas.

Contribuciones

• Hay ideas como tomar prestadas ideas del trabajo de Martin Thompson para crear un event loop rápido y agregar I/O asíncrona, entre otras.
• Si tienes interés, opiniones, sugerencias o preguntas, es posible ponerse en contacto.

[GN⁺]

Comentarios de Hacker News

• Lo asombroso de Erlang y BEAM es la profundidad de sus capacidades. Para el autor original, lo más valioso fue la Behavior/Interface de Erlang. Personalmente, creo que lo importante es que los recursos de desarrollo necesarios para construir sistemas complejos son mucho menores que en otros lenguajes. Para mucha gente, lo atractivo son los procesos ligeros y el modelo de programación

  • OTP incluye muchísimas funciones. Estamos trabajando en compilar Elixir para que pueda ejecutarse en dispositivos iOS. Usando la biblioteca ei de Erlang, se pueden compilar nodos desde C e interoperar con otros nodos de Erlang. Mediante la biblioteca rpc de Erlang, es posible hacer llamadas de funciones desde C e interactuar con aplicaciones de Elixir
  • Erlang ha resuelto muchos de los problemas con los que batalla el stack tecnológico moderno, y resolvió hace décadas los problemas de escalabilidad y costo de implementación. Sin embargo, en HN el interés por Erlang/Elixir no se ha traducido en adopción real, y muchas empresas están desperdiciando dinero intentando implementar por su cuenta cosas que el stack de Erlang ya ofrece gratis

• He trabajado con algunas personas que, junto con varios directivos, querían escribir un libro basado en su experiencia. Siempre tuvimos diferencias sobre cuáles eran los factores del éxito. Algunas personas sostienen que los procesos ligeros y el paso de mensajes no son la salsa secreta, pero pasan por alto que los Communicating Sequential Processes de Erlang no pueden separarse de esas características

  • Ejemplo: el programador de aplicaciones escribe código secuencial, y toda la concurrencia queda oculta dentro de los behaviors
  • Es fácil para un nuevo integrante empezar: la lógica de negocio es secuencial y tiene una estructura similar a la que quizá ya haya visto antes
  • Los supervisores y la filosofía de "dejar que falle" contribuyen a crear sistemas confiables

• Volví a interesarme en Erlang por los procesos ligeros y el paso de mensajes. Hasta ahora, los behaviors habían sido algo secundario

  • El proyecto consiste en llevar Flow Based Programming (FBP) visual a Erlang. FBP parece encajar bien con Erlang, y me sorprendió descubrir que ya existía algo así
  • Estamos usando Node-RED como herramienta de FBP, y la idea básica es conectar el frontend de Node-RED a un backend en Erlang y convertir todos los nodos en procesos

• Estaba buscando información sobre por qué Ericsson dejó de usar Erlang y sobre el despido de Joe

  • La respuesta corta es que Erlang quedó relegado cuando se cambiaron los nuevos proyectos a Java. Joe y sus colegas fundaron Bluetail en 1998, y luego fue adquirida por Nortel. Nortel era un gigante de las telecomunicaciones; en 2000 su acción llegó a $125, pero en 2002 cayó por debajo de $1. Esto se relaciona con el estallido de la burbuja puntocom y con la reducción del gasto en telecomunicaciones

• La fuerza de Erlang/Elixir no está en la implementación del modelo Actor, el matching de Prolog, la inmutabilidad o los behaviors, sino en el deseo de Joe de demostrar que se puede hacer más con menos recursos

  • Es un sistema bien diseñado y coherente, con una consistencia que rara vez se ve en otros lenguajes. No es perfecto, pero sí impresionante
  • Creo que en el mundo del software falta reconocimiento y aceptación del poder que tiene la simplicidad

• Erlang, OTP y BEAM ofrecen más que solo behaviors. La VM se parece a un kernel virtual, y proporciona supervisores, procesos aislados y modo distribuido. OTP ofrece módulos útiles como Mnesia (base de datos), contadores atómicos/tablas ETS (caché), entre otros

  • Hace un año, una consultora personal adoptó Erlang como lenguaje de backend. Exploramos el interior de BEAM para reemplazar un stack basado en TCP por QUIC e integrar parches en Rust

• El concepto más interesante de Erlang/BEAM es que la recuperación parcial viene integrada por defecto. Si aparece un estado inesperado, en vez de terminar todo el proceso o correr el riesgo de causar corrupción, se revierte al último estado conocido como bueno en el nivel más granular posible

• La razón por la que otros lenguajes y diseñadores de bibliotecas no copian la estructura de behaviors de Erlang es que las firmas de las funciones de behavior están estrechamente conectadas con otras capacidades de Erlang, en especial su uso particular de la inmutabilidad

  • Para lograr el mismo objetivo en otros lenguajes, no se debería copiar directamente el enfoque de Erlang. Recomiendo aprender de la forma en que Erlang construye software confiable, pero me opongo firmemente a portar tal cual su enfoque a otros lenguajes

• No estoy de acuerdo con lo que dice este artículo. Los behaviors son posibles gracias a la arquitectura base del sistema. Los behaviors no son una interfaz, sino algo más parecido a objetos abstractos en lenguajes como Java

  • El artículo de Joe muestra cómo construir sistemas confiables usando un conjunto dado de bloques tipo Lego

• Los behaviors no son tan interesantes. Existen también en otros lenguajes de programación. Lo interesante de BEAM es que lanzar errores resulta muy elegante. Lanzar errores, junto con la potencia de los behaviors, facilita capturar errores, reportar información de contexto y, en general, hacer que todo sea componible