beam_languages: a curated map of the languages that run on the BEAM

A document, not a package

The repository for beam_languages contains two files: a .gitignore and README.org. That is the whole artefact, and it is worth saying plainly, because the shape of the thing determines how you should use it.

The document is intended to list two things. The first is languages implemented to run on the BEAM, the Erlang virtual machine. The second is documents, meaning articles and presentations, about the hows and whys of writing languages to run on the BEAM. The second category is what makes it more than a list, because each entry often carries a pointer to the reasoning behind the implementation, which is usually the harder thing to find.

The naming is also stated plainly. For the moment, and for want of a better name, the author calls such languages BEAM languages, with the parenthesis that there are other Erlang VMs. That is a small concession that the term is a convenience rather than a standard, and it is the kind of precision that makes the rest of the document trustworthy.

The format is Org mode, with a generated table of contents and internal links between sections, which is why the file is README.org rather than README.md. It is a reading document, meant to be rendered, with entries as bullet lists under headings that group the languages by family.

The arithmetic of 57

The list is organised by family, and the count is broken down in the document itself.

First the 1 Erlang itself, then the 6 main Lisp-influenced languages, then the 25 statically-typed languages, then the 25 others. That is 57 languages in all.

The grouping is doing real work. The statically typed section is the largest because that is where most of the interesting work has happened: an implementation of ML, of Haskell, of Elm, of OCaml, of PureScript, of Idris, of Forth and of F#, all compiling down to the same virtual machine.

The others section is the catch-all, and from the structure of the document it is where the experiments and the one-off implementations live, including the languages with a start and end year attached. A name in parentheses with a year range, such as the 1993 to 2014 entry for the Haskerl family, is the author's own signal that a project is finished, and the date for an entry with a plus sign, such as 2016+, means it was still around when the entry was written.

Those dates are the most useful data in the list, and they are also the data most likely to be out of date. A plus sign tells you the project was alive at the time of the last edit, not that it is alive now, and the last push to the repository was on 2026-08-24 with no releases published.

The Lisp wave and why the count keeps moving

The document explains why the numbers are what they are, and it is a more interesting admission than it first appears.

At the December 2025 update, there were too many lisps implemented in erlang and (mostly) elixir in github to count. There are also quite a few language projects missed earlier, and projects which have not been updated since 2018 have not always been included.

That is the honest limit of the artefact. The BEAM is unusually friendly to Lisp implementations, because the runtime's process model, its message passing and its lack of mutable state make the translation of a Lisp into Erlang semantics unusually clean. The result is a long tail of dialects, and a maintainer keeping a list by hand cannot count them.

The Lisp section in the document shows the range. clojerl is Clojure for the Erlang VM, with a site and an online try-it. lfe is the older Erlang Scheme-like language from 2008. erlscheme is a Scheme implementation for the Erlang and OTP VM, marked as running until 2025. joxa ran from 2011 to 2020 and carries two Eric Merritt write-ups comparing it with LFE, one on their differences and one on it as a full featured Lisp on the VM. kapok ran from 2015 to 2018, and 'the concurrent schemer, from 2013 to 2014, is one of the more entertaining names in the list.

So the Lisp section is also a map of an ecosystem that came and went, and the honest conclusion is that the list is a snapshot of enthusiasm rather than a survey of what anyone still uses.

The statically typed half compiles other languages to Erlang

The statically typed section is where the list is most useful, because these are languages with compilers, specifications and design papers rather than one-file experiments.

Several of them are backends for existing languages. caramel is an Erlang backend to the OCaml compiler, so a program written in OCaml can target the BEAM. purerl is an Erlang backend for PureScript, described as PureScript to Erlang optimizing compiler, with a blog post introducing it. fez is a F# to core Erlang compiler experiment, and elchemy is an Elm syntax front-end for Elixir, converting Elm-style input into Elixir source code. purescript-backend-erl is a PureScript to Erlang optimizing compiler.

Others are languages in their own right that happen to target the same machine. gleam is a statically typed language for the Erlang VM and by far the most widely used of this group. hamler is a Haskell-style functional programming language running on the Erlang VM. erty is Erlang but with stronger support for types, which the entry expands as ERlang with TYpes. fika is a statically typed functional programming language for the web.

Then there are the dependently typed and proof-oriented entries, which are the most research flavoured: idris-erlang is an Idris package that compiles Idris source into Erlang source, which means it requires both Haskell and Idris; idris2-erlang is an Erlang code generator for Idris 2. cure is described as a strongly typed, dependently typed language for the BEAM with built-in finite state machines, a complete import system and a comprehensive standard library.

The unifying insight is that the BEAM is a good compilation target. Its abstract machine is small, its runtime model is documented, and the presence of Elixir and Erlang means there is a community of people who understand how to target it.

hirð and the arrival of coding agents

One entry in the list is dated 2026, and it is the most interesting one to read today.

hirð is described as a typed language for long-running agent systems on BEAM, with effect-row tracking, auditable tool effects, typed actors and OTP supervision. It has a Rust-implemented compiler that emits Erlang source, and it ships an LSP server and an MCP server that expose compiler queries, specifically type inference, effect rows and actor protocols, to language model agents.

That last detail is the reason this list is worth reading in 2026 rather than only as a curiosity. A language that exposes its own type checker and effect analysis over the Model Context Protocol is treating the compiler as a service for automated tooling, and the effect-row system is what makes a tool call auditable, since every effect is in the type rather than in a comment. Typed actors plus OTP supervision is the BEAM's concurrency model stated in the type system, which is a considerably stronger claim than a language that merely runs on the VM.

The entry also shows how the list is now partly about tooling and not only about languages. A compiler you can query programmatically is a different kind of artefact from a compiler you invoke, and for teams writing agents against a codebase, that distinction is the difference between a language that can be reasoned about automatically and one that cannot.

How to read the list, and where it will mislead you

Using this document well means understanding what it is for. It is a reading list with a taxonomy, maintained by one person, and the author asks to be told about anything missed through the usual channels, which is the invitation a community list extends.

The alternative for a broader sweep is named in the document itself. Many languages the author did not include are in Michał Łępicki's beam languages list on GitHub, and the two together cover more ground than either alone. The difference in approach is that this one is prose with commentary and links to design writing, while the other is a list.

The failure mode to watch for is treating the count as a measure of adoption. Fifty-seven languages on the BEAM is a statement about how easy the VM is to target, not about how many of them anyone uses. Most of the entries have a year range, and several have an end date in the past, which tells you the real distribution: a handful with a following, and a long tail of experiments by individuals.

For a team choosing a language, the list is a starting point rather than an answer, and the honest way to use it is to pick the two or three entries closest to your problem, follow the links, and read the design writing that the document points at. That second category, the articles and presentations, is the part that has not been superseded by anything, and it is the reason the list is still worth reading.

Editorial conclusion

beam_languages suits an engineer curious about the BEAM ecosystem who wants one place to see the Lisp dialects, the statically typed experiments and the abandoned prototypes in one list rather than forty repository tabs, and who values the links to the design writing as much as the names. It is the wrong choice if you want a maintained index with strict inclusion criteria, because the author says outright that the list is personal and that the count changes with each update, and it is the wrong choice if you need to choose a language, since a list of 57 with dates attached tells you little about which one is used in production. Verify three things before you rely on it: the year next to each entry, because the dates in parentheses are the author's own markers for when a project started and when it stopped, and the linked repositories, since several of the entries are single author experiments.

Frequently asked questions

Official sources

1. Issues
2. llaisdy/beam_languages on GitHub
3. README