Gleam doesn't compile to Erlang source anymore
- ID
- 32614
- Status
- summarized
- Published
- 06 Oct 2026, 4:08 PM
- Fetched
- 07 Oct 2026, 10:10 AM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://gleam.run/news/gleam-doesnt-compile-to-erlang-source-anymore/
- Source URL
- https://hnrss.org/best
Summary
- Score
- 5.0
- Created
- 07 Oct 2026, 10:12 AM
- Tags
- Audience
- developers
What happened
Gleam v1.19.0, released 5 October 2026 and written up by Louis Pilfold, replaces the compiler's Erlang code generator — rewritten by Giacomo Cavalieri — so it now emits Erlang abstract forms (a metadata-annotated tree normally produced by Erlang's tokeniser and parser, binary-encoded via Erlang's external term format) instead of Erlang source code. Loading that binary format skips the front half of the Erlang compiler, which the post says significantly reduces build times for Gleam projects on Erlang, and makes runtime location metadata point at the original Gleam source rather than the generated Erlang, so BEAM crash reports and stacktraces get accurate line numbers. The post also notes this could enable full debugger support (e.g. edb) though no work has been done on that, and cites a benchmark based on José Valim's langcompilebench (100 modules × 100 functions returning "hello world") while cautioning benchmarks are contrived; the excerpt is truncated before the actual numbers.
Why it matters
If you run Gleam on the BEAM, v1.19.0 changes what your production stacktraces look like: line numbers now map to your .gleam source instead of pointing at the nearest generated Erlang function, so existing crash-report tooling and error-tracking rules that keyed off Erlang line numbers will resolve differently. If you don't ship Gleam, there is nothing to decide here — the post gives no absolute benchmark figures in the excerpt, only a methodology, so don't quote a speedup number you haven't measured yourself. No Malaysian or Southeast Asian angle is present in this text.
Discussion angle
Abstract forms as a compilation target: does skipping Erlang's parser/tokeniser front-end make source-level debugging and accurate stacktraces a differentiator for BEAM languages, and would anyone here move a side project to Gleam just for that? The 299-point / 127-comment thread is the real signal that this is a live debate.