Gleam ya no compila a código fuente de Erlang — y eso acelera todo

Gleam acaba de dar un giro silencioso que lo hace mucho más rápido: en lugar de generar código fuente de Erlang, ahora compila directamente a formas abstractas.

Un cambio profundo en el compilador

Hasta Gleam v1.18, el compilador generaba archivos .erl que luego pasaban por el compilador de Erlang. Con v1.19.0, la nueva versión genera formas abstractas de Erlang (Erlang Abstract Forms) en formato binario y las carga directamente, saltándose la mitad frontal del compilador de Erlang.

Este cambio fue obra de Giacomo Cavalieri, que reescribió por completo el generador de código para Erlang con un diseño distinto.

¿Qué gana Gleam con este cambio?

El salto trae varios beneficios concretos. Primero, el rendimiento del compilador mejoró notablemente: los tiempos de compilación bajaron considerablemente en benchmarks de 100 módulos con 100 funciones cada uno.

Segundo, la información de ubicación ahora es perfectamente precisa respecto al código fuente original de Gleam, no al código Erlang intermedio. Esto significa que los números de línea en los stacktraces y crash reports de BEAM son mucho más exactos.

Tercero, la base de código del compilador mejora su calidad: el antiguo generador era uno de los más estables pero no seguía las convenciones modernas. Por último, como broma en la nota de lanzamiento, quizá se acabe para siempre el debate de llamar a Gleam un "transpilador" en tono peyorativo.

Benchmarks: compilación más rápida

Comparando v1.17.0 vs v1.19.0 en el benchmark langcompilebench de José Valim, el tiempo total de compilación baja drásticamente en un build desde cero. En builds incrementales (desarrollo normal) la ganancia es aún mayor, porque solo se recompilan los módulos modificados.

En una comparación ampliada con otros lenguajes (Go, Erlang, Elixir, Java, Elm, Rust, TypeScript, C#), Gleam con destino Erlang aparece entre los más rápidos, y con destino JavaScript también queda competitivo. Como advierten los autores, estos benchmarks son artificiales, pero dan una idea razonable de la velocidad.

¿Por qué no compilar directo a bytecode BEAM?

El equipo optó por generar formas abstractas en lugar de bytecode BEAM directamente. Esto aprovecha al máximo el backend probado y optimizado del compilador de Erlang/OTP, evita duplicar lógica compleja (optimización, análisis, empaquetado) y mantiene la compatibilidad con el ecosistema BEAM.

Conclusión

El cambio es técnico, pero el resultado es tangible: compilaciones más rápidas, depuración más precisa y un compilador más sólido. Para quien desarrolla en Gleam a diario, lo más importante es que ese tiempo de espera se reduce y los crash reports dejan de adivinar líneas.

Comparte esto si crees que los lenguajes funcionales deberían priorizar DX (experiencia de desarrollo) sin sacrificar fiabilidad.