Gleam ya no compila a código fuente de Erlang

Cambio en el backend de Erlang de Gleam

• Gleam ahora emite “formas abstractas” de Erlang (el AST/IR del compilador de Erlang) en lugar de código fuente de Erlang legible por humanos.
• Varios comentaristas señalan que esta es la misma representación que se usa ampliamente en el ecosistema BEAM (incluido Elixir y las parse transforms).
• Un comentarista critica inicialmente la vieja decisión de generar código fuente textual en vez de formas abstractas, llamándola redundante y propensa a errores.
• Un colaborador principal explica la decisión original: en ese momento, las formas abstractas no eran el “estándar” claro, la API de Core Erlang no era estable para un compilador externo en Rust, y emitir código fuente ofrecía una vía de escape hacia Erlang y permitía aprovechar las herramientas de compilación de Erlang.
• Ahora Gleam escribe directamente el Erlang Term Format; todavía existe un generador de código fuente de Erlang, principalmente para pruebas.

“Transpilador” vs Compilador

• El punto del artículo de que “transpilador” no es inherentemente peyorativo provoca debate.
• Algunos señalan que la antigua canalización sí era peor, pero por la implementación, no porque produjera código fuente.
• Otros argumentan que, si puedes volver a imprimir las formas abstractas como texto Erlang, la distinción entre “AST” y “código fuente” es en parte semántica.

Objetivos, casos de uso e interoperabilidad

• Gleam se describe como un lenguaje funcional de propósito general, tipado estáticamente y de estilo ML, orientado a la simplicidad, la seguridad y buenas herramientas.
• Objetivo principal para servidor: BEAM (la VM de Erlang). Objetivo secundario: JavaScript, principalmente para web/frontend u otros contextos alojados en JS (por ejemplo, aplicaciones web con Lustre).
• Un comentarista cuestiona por qué JS es un objetivo si Gleam no es “para UI”; otros responden que JS es útil más allá de las UIs y que tener un solo lenguaje para servidor, SSR y frontend tipado resulta atractivo.
• La interoperabilidad con Elixir es posible, pero no “sin fricciones” debido a los distintos sistemas de tipos.

Backends nativos / otros

• Algunos desearían que Gleam compilara a un objetivo nativo (por ejemplo, Rust, Go, C, Wasm, LLVM IR).
• Un colaborador principal argumenta:
  • Rust es un mal objetivo de compilación: compilador lento, no está instalado de forma generalizada, y su diseño para autores humanos no encaja bien como IR de backend.
  • El recolector de basura de Go y su modelo de goroutines no son ideales para el estilo inmutable y basado en procesos de Gleam.
  • IRs de más bajo nivel (C, Wasm, LLVM, Cranelift) serían más apropiadas si se siguiera una vía nativa.
• Soluciones alternativas como empaquetar BEAM en un único ejecutable (por ejemplo, mediante Gleepack) ya pueden producir binarios pequeños y portables.

Comparaciones entre lenguajes y curva de aprendizaje

• Comparaciones: Gleam se asemeja más a OCaml/Standard ML/Elm/F# que a Rust.
• Algunos creen que los usuarios de Rust pueden encontrar accesibles la sintaxis de Gleam y el pattern matching; otros advierten que las expectativas conceptuales de Rust (ownership, borrowing) no se trasladan y pueden causar confusión.
• Erlang vs Elixir vs Gleam:
  • Gleam: tipado, minimalista, sin macros, sin pattern matching en los encabezados de función (una concesión a la simplicidad).
  • Erlang: elogiado por algunos por sus matchers/guards y por una sintaxis sorprendentemente agradable.
  • Elixir: valorado por sus macros, integración con OTP, excelente REPL y un framework web maduro; preferido por algunos usuarios de Rust pese al tipado estático de Gleam.

Comunidad, ecosistema y adopción

• Varios comentarios elogian a la comunidad de Gleam como excepcionalmente amable, incluyendo transmisiones en directo y charlas educativas.
• Usuarios informan buenas experiencias construyendo proyectos reales (por ejemplo, APIs/servicios web, apps mediante Gleam + Lustre + Tauri).
• Algunos ven que Gleam se convierte en su stack por defecto; otros lamentan no tener proyectos de trabajo para usarlo.
• Un comentarista se preocupa de que, en una era de programación basada en LLM, la “amigabilidad con LLM” pueda convertirse en un filtro para la adopción de lenguajes de nicho, algo que le resulta desalentador.

Temas secundarios varios

• Tángente detallada sobre el uso de comas y las normas gramaticales en inglés; consenso: el estilo varía y a la mayoría de la gente le importa poco fuera de contextos formales.
• Breve discusión sobre integrar código generado por Gleam con herramientas como el depurador de Erlang de WhatsApp; se considera trivial si se pasan los flags de compilación.
• Crítica breve al branding de Gleam por parecer “como juguetes de niñas”, con rechazo por parte de otros que consideran esa inseguridad extraña o irrelevante.