Gleam 1.19 Skips Erlang Source, Cutting a 100-Module Build From 500ms to 120ms

Gleam v1.19.0, announced on October 5, 2026, no longer writes Erlang source files as an intermediate step on the way to BEAM bytecode. The compiler now emits Erlang abstract forms, and the project reports that a 100-module test project builds in about 120ms, down from about 500ms on v1.17.

What changed in the compiler

Louis Pilfold's release post says the Erlang code generator was "completely rewritten" by Giacomo Cavalieri. Instead of printing Erlang text that the Erlang compiler then parses, Gleam produces the parse tree itself, in Erlang's external term format, and hands it to the compiler's back half.

Erlang documents this format as The Abstract Format (OTP 29.1.1 edition). The page describes abstract forms as the standard parse-tree structure expressed as Erlang terms, and says compile:forms/1,2 accepts them directly as input. That is the door Gleam now uses.

The benchmark, and whose it is

The figures below are vendor-supplied. They come from the Gleam release post, on one test project of 100 modules with 100 functions each, and no independent party is named as having run them.

1. Gleam 1.19 (Erlang target)120 ms
2. Go200 ms
3. Gleam 1.19 (JavaScript target)400 ms
4. Gleam 1.17 (Erlang target)500 ms
5. Erlang600 ms
6. Java800 ms

Source: Gleam v1.19.0 release post, vendor-supplied, approximate values, October 5, 2026

The comparison against Go, Erlang and Java uses the same project shape, but the post gives the values as approximations. Gleam's own Erlang target went from roughly 500ms to roughly 120ms between v1.17 and v1.19, a fourfold drop. One generated project of identical modules says little about a real codebase with large dependency trees.

Stack traces that point at the right line

The change that a developer will notice first is not speed. The post says "The line numbers in BEAM crash reports and stacktraces are perfectly accurate, while previously they could be inaccurate". Because abstract forms carry location metadata, the locations can refer to the original Gleam source instead of generated Erlang.

Anyone who has chased a crash report into a generated .erl file knows the cost of that mismatch. The report named a line in code you never wrote.

Other items in v1.19.0

Area	Change
JavaScript target	Flatter pattern-match code via decision-tree assignment; short list literals built directly
Build tool	.app resource files generated for BEAM packages; --no-dev flag on compile-package
Language server	Go-to-definition, find-references and rename for field and argument labels
WebAssembly compiler	New format_source function for in-browser formatting

The post says all changes keep backward compatibility with existing Gleam code. It does not quantify the JavaScript-target gains, and the GitHub release page, when fetched, did not render the changelog text, so the post is the only source for the feature list.

Where this sits

Other toolchain stories on this site include Headstart, a Cargo tool, and VB6 Studio, a browser-based IDE. Gleam's route is its own: reuse an existing compiler's input format rather than add a stage.

The dependence cuts both ways. Gleam's Erlang target now relies on the abstract format that Erlang's maintainers define, so a change there lands on Gleam first. The post does not discuss that risk.

The next check is independent: a team with a real Gleam project of tens of thousands of lines reporting its own before-and-after build times on 1.19.