Gleam OTP – desarrollo de programas tolerantes a fallos y multinúcleo basados en actores

 (github.com/gleam-lang)
1 puntos por GN⁺ 2025-10-21 | 1 comentarios | Compartir por WhatsApp
  • Gleam OTP ayuda a desarrollar programas con tolerancia a fallos y rendimiento multinúcleo usando el modelo de actores
  • Se caracteriza por buscar seguridad de tipos completa y compatibilidad con Erlang OTP
  • Ofrece recuperación ante fallos y capacidades de autocuración mediante supervisores
  • Solo ofrece parte de las funciones de Erlang/OTP, y estrategias de gestión adicionales están actualmente en desarrollo
  • Soporta varios tipos de actores, incluidos procesos generales, actores y supervisores

Resumen de Gleam OTP

  • Gleam OTP es un potente framework de actores inspirado en la arquitectura OTP de Erlang, adecuado para implementar programas multinúcleo tolerantes a fallos
  • Es un proyecto de código abierto bajo la licencia Apache-2.0

Características y ventajas principales

  • Garantiza seguridad de tipos completa para actores y mensajes
  • Ofrece compatibilidad con Erlang OTP, lo que facilita la integración con entornos Erlang existentes
  • Brinda tolerancia a fallos mediante supervisores (supervisor) para detección de fallos, recuperación automática y gestión de terminación
  • Busca alcanzar un rendimiento equivalente al de Erlang OTP
  • Su documentación y ejemplos facilitan el aprendizaje y la aplicación en casos reales

Descripción por tipo de actor

  • Proceso (process)

    • Cumple el rol de bloque de construcción más básico dentro de OTP
    • Sirve como base para otros tipos de actores, pero no suele usarse directamente con frecuencia en aplicaciones Gleam

  • Actor (actor)

    • Es el tipo de proceso más utilizado y ofrece funcionalidades similares a gen_server de Erlang
    • Maneja automáticamente mensajes del sistema OTP y habilita funciones de depuración y trazado

  • Supervisor (supervisor)

    • Se encarga de iniciar otros procesos y de su supervisión y recuperación
    • Reinicia automáticamente los procesos hijo cuando ocurren fallos o excepciones
    • Mediante una estructura anidada de supervisores (supervision tree) forma la arquitectura de tolerancia a fallos de la aplicación
    • Se puede revisar la implementación detallada en la documentación de gleam/otp/static_supervisor y gleam/otp/factory_supervisor

Limitaciones y problemas

  • Actualmente los actores no soportan todos los mensajes del sistema OTP; los mensajes no soportados se ignoran
  • Algunas funciones de la API de depuración de OTP son limitadas
  • Si es necesario, se puede solicitar soporte para mensajes no implementados mediante la creación de un issue

Conclusión e importancia del proyecto

  • Gleam OTP amplía las fortalezas del ecosistema Erlang al lenguaje Gleam, y tiene gran importancia por permitir implementar seguridad de tipos y tolerancia a fallos multinúcleo
  • Es adecuado para aplicaciones donde la estabilidad y el rendimiento son importantes en producción
  • Es un proyecto de código abierto con alto valor para aprender y aplicar en la práctica para startups, desarrolladores especializados en TI y desarrolladores en general

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-10-21
Opiniones de Hacker News
  • Empecé un proyecto pequeño con gleam/lustre y hasta ahora estoy realmente satisfecho
    Si te interesan el tipado estático, un entorno sin null, lo funcional y los lenguajes de la familia ML, te recomiendo probar gleam
    Y además, por supuesto, corre sobre BEAM
    • Yo pienso lo mismo
      Instalé gleam y se me instalaron como 50 paquetes en mi sistema; supongo que deben ser paquetes relacionados con Erlang/Elixir
      Me pregunto qué pasaría si solo quisiera transpilar a JS. Tal vez sea un tema del empaquetado de mi sistema
      También estaría mejor si soportara Lua como objetivo de transpilación. Siento que, para incrustar un DSL en otros programas, Lua es tres veces más fácil que un runtime de JS
      Y sobre todo, lo que más me ha gustado hasta ahora es la comunidad. La calidad de las librerías y los recursos de la comunidad de gleam es altísima
      Me recuerda a la comunidad de Rust: la gente inteligente ya ha trabajado los problemas difíciles, así que es fácil encontrar buenas soluciones (lustre, squirrel, etc.)
      Otra característica es que se ve mucha experimentación e intentos creativos. Cosas que casi no se ven en ecosistemas de lenguajes grandes aquí sí destacan. A medida que la comunidad crece, el ambiente se siente muy acogedor
    • Me interesan todas las cosas que mencionaste. Pero todavía no entiendo bien BEAM ni OTP
      ¿Podrías recomendar por dónde empezar a aprender?
    • Desde la perspectiva de alguien que no tiene experiencia en nada de lo mencionado, me pregunto qué conviene aprender primero: gleam/lustre o elixir/phoenix
  • Me pregunto si quienes usan Gleam también usan algún framework web tipo Phoenix
    Estoy investigando porque sería genial poder usar Gleam junto con un framework como Phoenix
    Ahorita estoy preparando un proyecto nuevo en Python, pero si Gleam también es una opción viable, me gustaría intentarlo
    • Hay un video de una charla del desarrollador de Lustre mostrando una implementación con Gleam/Lustre de algo parecido a LiveView
      La ventaja es que puedes decidir muy fácilmente qué parte va en el frontend y cuál en el backend
      Enlace de YouTube
    • Todavía no hay un framework completo como Phoenix, Django o Rails
      Pero sí hay herramientas que se usan mucho al crear aplicaciones web
      Lustre es la herramienta básica de vistas y Wisp hace el papel de servidor
      Para SQL están squirrel y POG (es nuevo, pero está ganando popularidad)
  • PureScript es un lenguaje de programación funcional maduro que soporta un backend para Erlang
    Es una buena opción si necesitas una alternativa de tipado estático en BEAM
    Es como un dialecto de Haskell, con evaluación estricta y soporte para row polymorphism
    • El backend de JS de PureScript es maduro, pero el backend de Erlang y su ecosistema son muy pequeños en comparación con Gleam
    • En el sitio oficial y en el repo de GitHub solo veo que PureScript compila a JS; me da curiosidad de dónde sacaste lo del backend para Erlang
  • Me interesa mucho Erlang/BEAM, pero nunca he tenido tiempo de probarlo de verdad
    Me da curiosidad cómo se usa en el trabajo real. Si se construye toda la lógica del servicio ahí, o si solo se usa para partes específicas
    • Estoy liderando un equipo y haciendo una migración gradual a Gleam
      Llevamos el patrón de "functional core, imperative shell" al extremo y separamos a Gleam para encargarse de las tareas de cómputo pesado dentro de una base de código existente en Ruby on Rails
      Casi no usamos funciones de OTP, y Rails se enfoca solo en sus fortalezas naturales, como la UI web y la API HTTP
      Rails se encarga de preparar los valores de entrada de los jobs, y los datos del job se pasan a Gleam a través de Redis como un solo conjunto atómico de valores
      Hicimos un wrapper delgado en Elixir para manejar solo red y file IO, y la lógica de negocio queda en módulos de Gleam
      Estoy pensando escribir pronto un artículo con más detalle técnico sobre este enfoque. Es un tema que suele interesar mucho en HN
    • En TV Labs hacemos de todo con Elixir: servicios web, motores de emparejamiento en tiempo real, sandboxing de código Lua, comunicación con microcontroladores mediante protocolos binarios, machine learning y más
      Elixir es un excelente lenguaje de propósito general y tiene fortalezas en muchas áreas
      Para una conversación más detallada, revisa mi video de Developer Voices
      Enlace de YouTube
    • Te recomiendo pasar por elixirforum.com y conversar ahí
      Mucha gente construye sistemas serios usando solo Erlang/Elixir y BEAM, así que si tienes preguntas te van a responder bien
    • He visto ambos enfoques
      Una vez que entiendes bien OTP, se vuelve natural construir todo el sistema sobre eso
      Yo lo hice así durante 7 años, aunque también vi que a los desarrolladores nuevos les toma bastante tiempo acostumbrarse a este ecosistema
  • Para que Gleam sea tomado más en serio, creo que sería mejor no poner mensajes políticos fuertes en la página del proyecto
    No veo por qué hay que meter política en la página de un proyecto técnico
    No se trata de estar de acuerdo o no, sino de que en un espacio profesional sería preferible dejar fuera ese tipo de discusión
    Si no, la conversación se desvía innecesariamente del punto
    • ¿Te refieres a que aparece una sola vez, al final de la página, la frase "Black lives matter. Trans rights are human rights. No nazi bullsh*t."?
      Si alguien decide no usarlo por una sola línea como esa, entonces diría que está funcionando exactamente como se pretendía
    • Dijiste que "la conversación se desvía innecesariamente del punto"
      Pero más bien da la impresión de que fuiste tú quien la desvió
  • A mí me parece que el modelo de actores trae problemas de computación distribuida cuando necesitas compartir información entre procesos
    Desde mi punto de vista, para tolerancia a fallos y multicore es mejor usar memoria transaccional de software y un sistema de efectos funcionales, como en Scala/ZIO
    Eso no quita que el modelo de actores siga siendo útil cuando hace falta
    Además, si ves la madurez del ecosistema JVM, la observabilidad y lo probado que está en producción, supera a BEAM
    • Me parece una postura bastante peculiar
      Entiendo criticar las debilidades de BEAM, pero no tanto criticar justo lo que más fuerte tiene
      BEAM está diseñado para pasar mensajes inmutables entre green threads ligeros y baratos
      Tiene un sistema sólido de supervisión (supervisor trees), así que no tienes que preocuparte por data races ni por bloqueos de hilos
      Todo eso viene integrado de base, sin boilerplate
      Gracias a la inmutabilidad, el rendimiento también es sorprendentemente bueno
      Al final, BEAM es una plataforma especialmente optimizada para tolerancia a fallos y sistemas distribuidos/concurrentes
    • Hay una parte que no se mencionó: Erlang (la base de gleam) es un lenguaje que ha logrado 99.9999999% de uptime
      Uno de los grandes factores que permiten esa durabilidad es su infraestructura robusta de supervisión y entre máquinas
      Es un lenguaje que inspiró enormemente la aparición de los sistemas de actores
      Literalmente, Erlang existe para esta sola cosa, y la hace muy bien
    • Dijiste que "el modelo de actores tiene dificultades con lo compartido entre procesos", pero en realidad el modelo de actores copia datos o transfiere la propiedad mediante paso de mensajes
      Si hay datos que de verdad deban compartirse, entonces necesariamente tienen que ser inmutables
    • Me da curiosidad si podrías dar un ejemplo de una situación donde no puedas pasar datos mutables como estructuras inmutables
      Lo único que se me ocurre son cálculos numéricos extremadamente pesados, pero en esos casos no lo escribirías directamente en elixir o erlang, sino como un NIF
    • En Elixir/Gleam/OTP, los programas son en su totalidad conjuntos de procesos independientes
      Aunque no uses explícitamente el patrón actor, el paso y la coordinación del estado ya son problemas resueltos
      Tienes todas las primitivas básicas: tasks, agents, GenServer, Supervisor, etc.