Gleam, el lenguaje con seguridad de tipos construido para la máquina virtual Erlang y los entornos de ejecución de JavaScript, ya no escribe su salida de Erlang como código fuente plano. En cambio, ahora genera formas abstractas de Erlang — una representación interna que el compilador de Erlang lee directamente, omitiendo el paso de escribir código legible por humanos. El cambio se incluyó en Gleam v1.19.0, y el desarrollador Giacomo Cavalieri realizó el trabajo durante los últimos meses.
La transición es importante para los programadores de Gleam, quienes ahora obtienen compilaciones más rápidas, informes de fallos más precisos y una base de código más limpia. También cierra la puerta a una palabra que nadie quería escuchar: transpilador.
Lo que hace el cambio a la forma abstracta
Anteriormente, Gleam se compilaba a código fuente de Erlang, al igual que cualquier otro lenguaje que apunta a BEAM. Ahora produce formas abstractas de Erlang, una estructura similar a un árbol anotada con metadatos que el compilador consume internamente. Este formato tiene una codificación binaria que utiliza el formato de términos externos de Erlang, lo que significa que Gleam puede alimentarlo directamente al compilador de Erlang sin tocar nunca un archivo.
El resultado es una compilación completa que se ejecuta más rápido, según los puntos de referencia que se muestran en el anuncio. La diferencia es particularmente llamativa para proyectos grandes, donde el compilador dedica tiempo real a analizar y validar el código que la forma abstracta ya contiene.
Por qué importan los números de línea
Los números de línea precisos en los informes de fallos eran un problema antes de este cambio. Cuando un proceso BEAM falla, el entorno de ejecución de Erlang informa el número de línea de la función más cercana en el código Erlang generado, no la fuente original de Gleam. Eso significaba que la depuración a menudo implicaba leer un archivo generado para encontrar la línea de código real que falló.
Ahora, los metadatos permanecen adjuntos a la fuente original de Gleam. Un informe de fallos apunta a la línea correcta en el archivo de Gleam, en lugar de la función más cercana en el código generado. Esta es una mejora en la calidad de vida para cualquiera que haya pasado horas persiguiendo un error a través de código generado.
El anuncio señala que estos metadatos también podrían permitir el soporte completo de Gleam en depuradores como edb, aunque el equipo de Gleam no ha realizado ningún trabajo en ese sentido todavía.
Las ganancias de rendimiento
Los datos de referencia provienen del proyecto langcompilebench de José Valim, que mide el tiempo tomado para compilar 100 módulos que contienen 100 funciones cada una, todas devolviendo una cadena «hello world». El test es simple, pero es consistente entre los lenguajes, lo que lo hace útil para comparación incluso si no refleja la complejidad del mundo real.
El gráfico muestra una mejora clara entre v1.17.0 y la recién lanzada v1.19.0. El test es una compilación completa desde cero, sin almacenamiento en caché, por lo que mide el peor caso posible. En el desarrollo normal, donde el compilador solo toca archivos modificados, la aceleración sería aún más notable.
Cómo se compara Gleam con otros lenguajes
El langcompilebench original incluía solo Erlang, Elixir y Gleam. El anuncio extiende el test a una gama de lenguajes de programación populares, incluyendo Gleam compilando a JavaScript. Aquí es cómo se comparan los resultados:
| Lenguaje | Tiempo de Compilación |
|---|---|
| Erlang | Línea Base |
| Elixir | Más rápido que Erlang |
| Gleam (Erlang) | Más rápido que Elixir |
| Gleam (JavaScript) | Más lento que Erlang |
La tabla completa muestra que Gleam se mantiene a la par frente a los lenguajes con los que compite, y el objetivo JavaScript agrega una comparación útil para los desarrolladores que trabajan en ambos entornos. El anuncio tiene cuidado de señalar que este es un punto de referencia construido artificialmente, no una medida definitiva del rendimiento en el mundo real.
¿Por qué no bytecode?
Una pregunta obvia es por qué Gleam no apunta directamente al bytecode de BEAM. La respuesta es que el bytecode no está fijo. Cada nueva versión de la máquina virtual puede agregar o eliminar funcionalidad, lo que significa que un generador de bytecode tendría que seguir el ritmo de los cambios continuos.
El anuncio enmarca esto como una restricción de recursos. Gleam es un proyecto comunitario respaldado por patrocinios, con una fracción de las finanzas disponibles para los lenguajes respaldados por empresas o financiados académicamente. El equipo argumenta que la compilación a formas abstractas es el uso más eficiente de sus recursos limitados.
«Compilar a formas abstractas de Erlang es el punto óptimo de costo-beneficio para Gleam hoy.»
El precedente de Elixir
El anuncio señala que Elixir en sí mismo se compila a Erlang a través de formas abstractas. El razonamiento es simple: si es suficiente para Elixir, es suficiente para Gleam.
Ese precedente tiene peso, dado que Elixir se compila a formas abstractas. Si los encargados de mantenimiento de Erlang consideran las formas abstractas como el camino estándar, tiene sentido que un lenguaje más joven siga la misma ruta.
El panorama general
La reescritura no es solo un parche de rendimiento. También mejora la calidad del código que genera el compilador, según el anuncio. El generador de código Erlang fue una de las partes más antiguas y estables del código base de Gleam, y aunque no estaba causando problemas, no seguía los estándares y convenciones actuales del equipo.
El nuevo generador es descrito como excelente, y el anuncio argumenta que eleva el listón para el compilador en su conjunto.
Lo que esto significa para los desarrolladores
Para un programador de Gleam, la conclusión práctica es simple: las compilaciones son más rápidas, y la depuración es más precisa. La forma de salida abstracta significa que el compilador dedica menos tiempo a realizar tareas que el compilador BEAM ya maneja, y los metadatos significan que los informes de fallas apuntan a la línea correcta de código.
El anuncio termina con un chiste: el equipo nunca más tendrá que escuchar a alguien usar la palabra «transpilador» de manera despectiva.
Esa es una pequeña victoria, pero es una victoria real. Un lenguaje que se compila a formas abstractas no es un transpilador en el sentido despectivo — es un compilador que habla directamente el idioma nativo del BEAM.
Material de origen: “Gleam ya no compila a código fuente de Erlang,” gleam.run.
Recibe El Cuaderno.
Las mejores historias del día y cada veredicto nuevo, en español claro, en tu correo a las siete. Un correo al día, nada más.