Gleam 1.19.0 Skips Erlang Source, and a Nightly Broke compile-package

Gleam 1.19.0, released Oct. 5, no longer writes Erlang source text on the normal build path. The compiler now emits Erlang's abstract format, a parsed representation that skips the front half of the Erlang compiler, according to the changelog.

That is the claim behind a Hacker News headline, "Gleam doesn't compile to Erlang source anymore", and it is half right. Gleam is a statically typed language that runs on the Erlang virtual machine, and for years its output was readable .erl files that other tools picked up. The abstract format changes the default. One command, gleam compile-package, was nearly caught in the change.

What the changelog promises

The changelog says the format "supports mapping every generated Erlang line back to its corresponding line in the original Gleam source file", which is what makes stack traces point at Gleam code instead of generated Erlang. It also says compile times "have been reduced for a typical Gleam package" when targeting Erlang, and gives no figure. The lexer was tuned too, now using "byte indexing with an ASCII fast path instead of iterating over characters."

The release post, as summarised by daily.dev, says the team chose abstract forms over emitting BEAM bytecode directly because bytecode would need continuous updates to track Erlang VM changes and would mean reimplementing existing compiler optimisations, a burden for a small, sponsor-funded project.

A smaller change guards against Erlang/OTP 29's built-in types: a Gleam type named Record is now renamed record_ in generated Erlang type definitions. Error messages are also more fault tolerant on unsupported binary operators in constants. The changelog credits Giacomo Cavalieri, John Downey, Andrey Kozhev and Louis Pilfold, among others.

The nightly that stopped producing .erl files

On Sept. 6, a contributor using the handle yoshi-monster filed issue 6281 reporting that the nightly build's gleam compile-package had stopped producing .erl files and wrote .abstr files only. The issue carried the labels "help wanted" and "high priority."

The reporter's argument was about downstream tooling: "gleam compile-package is used by other tools to integrate with Gleam", and "it's quite common for them to search for the produced Erlang source code files, compiling them with their own respective toolchains." The reporter proposed that the command keep producing .erl files and put .abstr behind an optional flag, if at all.

Date	Event
Sept. 6	Issue 6281 filed against the nightly
Sept. 19	Pull request 6291 merged
Oct. 5	Gleam 1.19.0 released

The fix, and what could not be confirmed

Pull request 6291, authored by giacomocavalieri and merged by lpil on Sept. 19, made compile-package generate the textual format again. The reviewer asked for test coverage so the regression could not return, and the tests landed in the project's test-commands suite. The merge predates the 1.19.0 release by 16 days.

The 1.19.0 changelog text does not mention the fix, so The Terminal could not confirm from the release notes that 1.19.0 ships with compile-package writing .erl. Maintainers of build integrations should test against the release rather than assume. For comparison with other toolchain work this week, see how Rust's Headstart patch set chases build time and how a viral project stopped taking outside contributions.

The changelog gives no date for a Gleam release that would put a number on the compile-time gain.