By ByteBot
Gleam v1.16 landed on April 24 with the fix that JavaScript-target developers have been waiting for: source maps. Before this release, a runtime error in the browser showed you the compiled JavaScript — line numbers pointing nowhere useful, stack traces referencing internal stdlib internals. Now errors point to your actual Gleam source. This is the last major blocker for serious frontend work in Gleam, and it arrives alongside a 27% compile speedup and a language server that no longer goes blind when one module breaks.
What Gleam Is (And Why It Is Not Just Another Elixir)
Gleam is a statically typed functional language that compiles to two targets: the Erlang VM (BEAM) for backend services, and JavaScript for browsers, Node.js, Deno, and Bun. No null values. No runtime exceptions. No any escape hatch. The compiler either proves your program correct or refuses to build it.
Elixir developers will recognize the BEAM runtime and the Hex package ecosystem, but Gleam is a different bet. Elixir is dynamically typed and offers a powerful macro system; Gleam trades that flexibility for compile-time guarantees and, crucially, JavaScript output. You can call Erlang and Elixir packages directly from Gleam, which means you inherit the BEAM ecosystem without starting from scratch.
The dual-target story is Gleam’s actual differentiator. Define a User type once; use it in your BEAM backend and your Lustre frontend. A type mismatch between your API response shape and your UI component is a compile error, not a 2am production incident. No other BEAM language does this.
Source Maps: What Changed in 1.16
When Gleam compiles to JavaScript, it generates standard ES modules. Before v1.16, when something crashed in the browser, you were staring at the compiler’s output — generated code that bears little resemblance to what you wrote. Setting a breakpoint in DevTools meant hunting through transpiled logic to find the original line.
Source maps solve this. They are metadata files (the V3 standard format — the same spec TypeScript uses) that map every line of compiled JavaScript back to the original Gleam source location. Browsers and JavaScript runtimes read these automatically. The result: stack traces show auth/user.gleam:22, not gleam_stdlib.mjs:437. Breakpoints set in Chrome DevTools, Firefox, or Safari Web Inspector land on your Gleam code.
Enabling it takes one line in gleam.toml. The official 1.16 announcement covers the full configuration details:
[javascript]
source_maps = trueIf you are using Lustre dev-tools or serving the build directory directly, nothing else is needed. The .map files are generated alongside your compiled .js files and picked up automatically.
The Other Wins in 1.16
Source maps get the headline, but two other improvements matter for day-to-day work.
Failed module pruning. Previously, when one module failed to compile, the language server would stall on that sub-tree — meaning autocomplete, diagnostics, and hover types went dark across anything that depended on it. v1.16 prunes the failed sub-tree and continues analyzing the rest of the project. During a refactor or an incremental migration, this is the difference between a productive IDE session and flying blind.
Compilation speed. Median compile time dropped from 14.74ms to 10.72ms — a 27% improvement. Gleam was already fast; this makes it faster. On large projects, build pipeline latency compounds quickly, and Gleam’s sub-15ms baseline is legitimately competitive with any language in this space.
Why This Matters in 2026
The AI-assisted development era has produced a counterintuitive trend: stricter type systems are becoming more valuable, not less. GitHub’s data shows that Copilot-generated code requires 25% fewer corrections in strongly typed codebases. When an AI agent writes a function, types are the spec it follows — and the guarantee that the rest of the codebase will not silently break when that function ships.
TypeScript overtook Python on GitHub in August 2025 partly for this reason. Gleam takes it further. There is no any. There is no implicit type coercion. The compiler provides a level of correctness guarantees that TypeScript, with all its escape hatches, cannot match. For teams leaning on AI-generated code, that strictness becomes a feature, not a constraint.
The BEAM side adds fault tolerance that cloud-native Kubernetes architectures approximate but cannot replicate. WhatsApp runs on Erlang. Discord migrated millions of concurrent users to Elixir. Gleam inherits that runtime while adding a type system those platforms never had.
Adoption and Production Evidence
Gleam has 21,400 GitHub stars and was the second most-admired language in the 2025 Stack Overflow Developer Survey — 70% of current users want to keep using it. By any measure, this language has moved past hobbyist status.
Uncover, a marketing analytics platform, runs its Gleam test suite at 1,900 tests per second — roughly 50 times faster than their other backend languages. They cite zero null pointer errors and zero unexpected type crashes in production. Read the full Uncover case study for the implementation details. With 125 companies now tracking Gleam usage, the ecosystem is past the “interesting experiment” threshold.
Who Should Take a Closer Look
If you are building a full-stack application where the same domain types need to be shared between a backend service and a browser client, Gleam’s dual-target compilation is worth serious evaluation. The source maps shipping in v1.16 remove the last legitimate reason to wait on the JS side of that story.
Elixir developers familiar with BEAM who want compile-time type guarantees should read the Uncover case study and the 1.16 announcement. The transition cost is lower than expected — the Hex ecosystem carries over, and Gleam’s syntax is cleaner than most expect. The Gleam roadmap shows what is coming next.
