Why Gleam’s type-safe Erlang VM language matters now

The BEAM and Rust-like safety

Gleam, an actor-based highly-concurrent functional language running on the Erlang virtual machine (BEAM), has reached version 1.0, which provides a guarantee of backward compatibility for production systems. It uses an actor-based concurrency system to run millions of tasks. These tasks scale easily because of immutable data and a garbage collector that never stops the world. I see a clear bridge for Rust developers who want a gentler concurrency model without systems programming overhead. Elixir developers will recognize the pipelining syntax and pattern matching.

It stays small.

The language follows the line of strong statically-typed languages like Elm, OCaml, and Rust. It uses immutable data structures with structural sharing. Concurrent access to mutable state happens through actors or Erlang’s in-memory key-value database, ETS. The compiler, which the team wrote in Rust, produces friendly error messages. In version 1.7.0, the compiler monomorphises record updates to remove runtime conditional logic. The developer experience benefits from a well-developed LSP that provides features like rename and code actions to generate decoders for custom types. You can use the use <- expression to handle errors, though you may still need to pair it with result.replace_error_type when functions return different error types. The compiler also includes support for pattern assertions with custom messages for debugging crashes. I find that printing values for debugging is tedious because everything requires manual coercion to a string.

Interop and the JavaScript target

Gleam compiles to JavaScript, which allows teams to write a backend web API and a website frontend using the same language. This setup enables code sharing between both platforms. A team can enjoy a productive type-based programming style across the entire application stack.

The interop is smooth.

Gleam provides zero-cost interoperation with other BEAM languages, including Erlang, Elixir, and LFE. You can mix Elixir and Erlang code in a Gleam program because the Gleam build tool compiles Elixir dependencies and source files. The compiler uses a specific syntax for importing external functions. Gleam also supports labelled arguments to allow function parameters to appear differently to the caller. The compiler also supports bit array slicing as a constant time operation on JavaScript.

Will a full-stack web framework emerge?

Production reality and ecosystem

I find that Gleam is production-ready. One developer ran a site for six months without outages, where memory usage hovered around 210 MB on a 512 MB cap. This site handled over 2000 requests per second on a single CPU core. If you know the basics, you will find the package manager works via Hex.

The ecosystem is young.

Many packages have not reached version 1.0. Significant development continues, and some minor dependencies introduce breaking changes. You will likely use Erlang or Elixir libraries frequently because the Gleam ecosystem is new. I must note that Gleam is more distanced from Erlang than Elixir is, because type safety is not a straight fit to the BEAM. This means you might need to write thin Erlang FFI modules to normalize data from dynamic structures. You should know that using Gleam requires an Erlang installation for BEAM targets or a runtime like NodeJS for JavaScript targets. If you are an Elixir user, you will find that Ecto, Phoenix, and LiveView are not fully usable without Elixir glue code to interface with them. The build tool uses rebar3 to compile Erlang packages, and it now sets the REBAR_SKIP_PROJECT_PLUGINS variable to reduce compile times. One developer used a process registry library called Chip to group websocket connections into groups for broadcasting, which helped manage multiple users collaborating in a document.