Gleam: el lenguaje que compila a Erlang y JavaScript

Qué es Gleam y por qué debería importarte

Gleam es un lenguaje funcional de tipado estático creado por Louis Pilfold. Su rasgo distintivo es que no apunta a la máquina directamente: compila a BEAM, la máquina virtual de Erlang, y también a JavaScript. El mismo código puede correr en un backend de telecomunicaciones o dentro de Node.js.

Llegó a su versión 1.0 en 2024 y desde entonces avanza rápido. Según el relevamiento The Grand Programming Languages Spectrum, la versión 1.19 ya compila a formas abstractas de Erlang en lugar de código fuente, lo que acelera las builds y mejora la precisión de los stack traces.

Para un founder, la pregunta no es si el lenguaje es elegante. Es si reduce el costo de construir y mantener un sistema. Y ahí Gleam tiene argumentos concretos.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Tres ideas que explican el atractivo de Gleam

El autor del artículo original, que viene de escribir Rust, resume el atractivo en tres características centrales:

El operador pipe (|>). Encadena funciones sobre datos sin anidar llamadas. La variable se pasa como primer argumento. Es la alternativa de Gleam a los métodos encadenados de los lenguajes orientados a objetos.
El patrón use. Resuelve el «tower of callbacks» típico de JavaScript. use param <- some_func(arg) es azúcar sintáctico para pasar una función como último argumento, evitando la indentación en cascada.
Tail-call optimization (TCO). Gleam no tiene bucles: la iteración se hace con funciones sobre listas o con recursión. El compilador reutiliza el frame de pila cuando la llamada recursiva es lo último que hace la función, así que la recursión profunda no agota la memoria.

Si tu equipo viene de TypeScript o Python, el pipe y el patrón use se entienden en una tarde. La recursión con TCO es la que exige cambiar el chip.

OTP: el argumento que sí mueve la aguja

BEAM no es solo un runtime. Trae OTP, el conjunto de librerías que Ericsson construyó para sistemas telefónicos que no podían caerse. OTP expone actores: procesos livianos que guardan estado y se comunican por mensajes. Cuando los pones bajo un supervisor, la aplicación tolera que un actor falle sin arrastrar al resto.

El autor del artículo original lo ilustra con un caso real de su equipo: un scheduler de jobs escrito a mano en Go, varios workers y una interfaz en Node.js, todo desplegado como pods separados en Kubernetes. Su propuesta es reescribir la parte de scheduling como actores dentro de una sola aplicación Gleam, y compilar la interfaz a JavaScript. Menos APIs REST duplicadas, menos superficie de despliegue.

La comparación con Kubernetes es inevitable, pero el propio autor marca la diferencia clave: un nodo OTP es un único proceso del sistema operativo y todos los actores comparten memoria, mientras que Kubernetes da a cada pod su propio contenedor y los reparte entre máquinas. OTP no tiene scheduler de clúster ni aislamiento por contenedor: los nodos los despliegas tú.

Para un equipo chico, esa distinción importa. Si tu problema es coordinar procesos y manejar fallos, OTP te da el patrón sin la factura de un clúster.

El lado B: ecosistema joven y talento escaso

Ningún lenguaje es gratis. El autor del artículo original, que admite estar en la fase de enamoramiento, lista tres objeciones honestas:

El ecosistema es pequeño. Es la consecuencia de ser un lenguaje joven. Se mitiga porque Gleam puede llamar funciones externas de Erlang, Elixir y JavaScript, pero la comunidad prioriza paquetes nativos de Gleam y todavía hay huecos.
El lenguaje es demasiado simple. El autor no lo ve como un defecto, pero reconoce que la ausencia de macros o de currying puede espantar a algunos equipos.
BEAM es una peculiaridad. El autor no podía nombrar una gran empresa que lo usara, aunque una búsqueda rápida muestra que WhatsApp, Discord y Pinterest, además de Cisco, Nintendo y el NHS británico, dependen de él. Erlang y BEAM sostienen plataformas enormes por su fiabilidad, pero no tienen el marketing de «Made in Rust».

El dato de adopción lo confirma: en la encuesta de Stack Overflow de 2026, Gleam aparece en el puesto 41 de popularidad y con un 52,3% de usuarios que quieren seguir usándolo. Es decir, gusta mucho entre quienes lo prueban, pero casi nadie lo usa todavía, y las ofertas de trabajo son prácticamente inexistentes.

Qué significa esto para tu startup

Gleam no es un reemplazo de tu stack principal. Es una herramienta para problemas específicos donde la concurrencia y la tolerancia a fallos valen más que la disponibilidad de talento.

Pilotea en un servicio acotado, no en el core. Elige un worker, un scheduler de jobs o un servicio de mensajería interno y escríbelo en Gleam. El costo de adopción es bajo porque puede llamar librerías de Erlang, Elixir y JavaScript sin fricción. Si funciona, escalas; si no, el blast radius es mínimo.
Explota el doble target para eliminar APIs duplicadas. Gleam compila a BEAM y a JavaScript, así que puedes definir los tipos una sola vez y compartirlos entre el backend y la interfaz. Eso es exactamente lo que el autor propone para su scheduler: en lugar de mantener dos APIs en sincronía, un solo conjunto de definiciones de tipos.
Revisa tu cuello de botella antes de elegirlo. Si tu restricción es contratar rápido, Gleam juega en contra: el ecosistema es joven y la oferta de desarrolladores es casi nula. Si tu restricción es la fiabilidad de un sistema concurrente con un equipo pequeño y senior, el cálculo cambia.

Conclusión

Gleam resuelve un problema concreto: escribir servicios concurrentes y tolerantes a fallos con tipos estáticos, sobre un runtime que lleva décadas probándose en sistemas que no pueden caerse. Su sintaxis simple y su capacidad de compilar a JavaScript lo vuelven accesible incluso para equipos que nunca tocaron un lenguaje funcional.

El precio es la inmadurez: ecosistema chico, poca oferta de talento y un runtime que, aunque sostiene plataformas gigantes, no tiene un gigante tecnológico empujándolo. Para un founder, la decisión no es ideológica. Es una apuesta acotada: probarlo donde el riesgo es bajo y la ganancia en resiliencia es alta.