Gleam v1.19.0 shipped on October 5, 2026 with a change that rewrites how the compiler works at its core: it no longer generates Erlang source code. Instead, Gleam’s Erlang target now produces Erlang abstract forms — the binary intermediate representation that Erlang’s own compiler creates internally after parsing. The result is roughly 2x faster full builds and, finally, BEAM stacktraces that point to your actual Gleam source lines instead of generated Erlang files nobody asked to read.
From Text Files to Trees: What Gleam Now Generates #
The old compilation path looked like this: Gleam source went through the Gleam compiler, out came .erl text files, and those files got handed to the Erlang compiler for tokenization, parsing, and the rest of the pipeline. That worked, but it meant the Erlang compiler was redoing work that Gleam’s compiler had already done conceptually.
Erlang abstract forms are what Erlang’s tokenizer and parser produce internally — a metadata-annotated binary tree representing Erlang syntax, encoded using Erlang’s external term format. By outputting this format directly, Gleam now skips the front half of the Erlang compiler entirely. The generated binary is loaded and processed starting from the middle of the pipeline, not the beginning. The official Gleam v1.19 announcement describes this as a complete rewrite of one of the oldest parts of the codebase.
Build Times Drop Roughly 2x #
The Gleam team benchmarked compilation of 100 modules with 100 functions each. Version 1.19.0 compiled roughly twice as fast as v1.17.0 on a fresh build. In that benchmark, Gleam (targeting Erlang) also outpaced Elixir, Rust, and TypeScript — though Go remained faster.
One honest caveat: this is full, from-scratch compilation. Incremental builds during active development were already fast and see smaller relative gains. However, for CI pipelines where every build is a fresh compile, 2x matters significantly.
Gleam Abstract Forms Fix BEAM Stacktraces #
This fix is arguably more impactful day-to-day than the build speed improvement. Previously, BEAM crash reports showed line numbers from generated Erlang source code — not your actual Gleam files. Debugging meant mentally mapping through generated files to find where in your Gleam code a crash originated. That’s a painful extra step, especially in production incidents.
Abstract forms carry location metadata accurate to the original Gleam source. According to the release notes, line numbers in BEAM crash reports and stacktraces are now “perfectly accurate” — meaning they reference exact lines in your .gleam files. Additionally, this richer metadata opens the door to full debugger support through tools like edb, the Erlang Debugger. That capability isn’t available yet, but the architecture now supports it.
Same Path Elixir Took — For Good Reason #
Gleam isn’t the first BEAM language to make this architectural choice. Elixir has compiled to abstract forms since its early days. The Elixir team’s reasoning applies here too: targeting BEAM bytecode directly would require continuously tracking bytecode changes across every OTP release, which evolves with each VM version. That’s maintenance debt that doesn’t pay off for a community-funded project when abstract forms provide the same benefits without the churn.
The convergence on abstract forms also quietly retires the “transpiler” criticism sometimes leveled at Gleam. Generating the Erlang compiler’s own internal representation is a different class of compilation than generating text for another tool to parse. The Hacker News discussion (250 points, 103 comments) reflected genuine enthusiasm — along with the usual BEAM community debates about native targets and JavaScript compilation support. The core reaction to the speed and debugging improvements was positive across the board.
The change is transparent to existing users. No migration steps, no configuration changes. Existing Gleam projects rebuild normally and immediately benefit from faster compilation and accurate stacktraces. The oldest major subsystem in the Gleam compiler has been replaced with a modern implementation that also happens to be faster. That’s the kind of infrastructure work that compounds quietly.
Key Takeaways #
- Gleam v1.19.0 (October 5, 2026) replaces Erlang source code generation with Erlang abstract forms — a complete rewrite of the compiler’s Erlang backend
- Full build times drop roughly 2x; BEAM stacktraces now point to exact Gleam source lines instead of generated Erlang files
- Abstract forms are the same compilation target Elixir uses, avoiding the maintenance cost of tracking BEAM bytecode changes across OTP versions
- No migration needed — the change is transparent to existing Gleam projects
- Richer metadata enables potential future full debugger support via tools like edb