Gleam 1.19 stops generating Erlang source and emits Erlang abstract forms instead
Serguey Asael Shinder1 min readGleam v1.19.0, released on 5 October, replaces the compiler's Erlang code generator. Gleam used to generate Erlang source code and hand it to the Erlang compiler; it now generates Erlang abstract forms, the intermediate representation the Erlang compiler normally builds by running its own tokeniser and parser.
Why that matters, per the announcement.
- Faster builds. Abstract forms have a binary format that can be loaded directly, skipping the front half of the Erlang compiler. The post reports a significant reduction in build times for Gleam projects on Erlang, measured on José Valim's langcompilebench (100 modules of 100 functions each, compiled from scratch without caching), comparing v1.17.0 with v1.19.0. The first stage of the rewrite already shipped in v1.18.0.
- Accurate locations. Runtime location metadata now refers to the original Gleam source, so line numbers in BEAM crash reports and stack traces are exact. Previously they referred to generated Erlang and could point only to the nearest function.
- Cleaner compiler code. The old generator was one of the oldest parts of the codebase and did not follow current conventions.
Why not BEAM bytecode. The post explains why Gleam did not go one step further and generate bytecode itself: unlike Erlang source and abstract forms, BEAM bytecode is not fixed, and each VM release can change it. Generating it directly would mean tracking those changes forever and giving up the Erlang compiler's optimisations.
The announcement itself warns that the benchmark is contrived: it compiles only a small subset of each language's features, so it is a rough comparison rather than a conclusion.