Skip to content(if available)orjump to list(if available)

The Beam

The Beam

24 comments

·May 9, 2025

schultzer

One thing that is great about Erlang’s pattern matching is that it makes it extremely approachable for writing, lexer, parser and compilers in it: https://github.com/elixir-dbvisor/sql and with Elixir macros and sigils then you can embed other languages like sql and zig to name a few!

wk_end

Does Erlang/Elixer have any edge over Ocaml or Haskell in that niche? They also have pattern matching, of course, and strong static types tend to work nicely for compilers too.

Of course, the big superpower they have is the BEAM and the robust multiprocessing support there, but that’s not especially helpful for compilers…or is it?

Munksgaard

As someone who has used both SML, Haskell, Rust and Elixir professionally: No, not really.

Access to the BEAM is nice, but unless you're targeting the BEAM in your compiler I don't see any benefit. Even if you're targeting the BEAM, you might decide to use another language, cf. Gleam: https://github.com/gleam-lang/gleam/

Edit: Actually, one thing I will mention is the superior support in Elixir/Erlang for pattern matching bitstrings[0]. Not usually helpful in compilers, but an evolution of pattern matching that other languages should take up, in my opinion.

0: https://hexdocs.pm/elixir/Kernel.SpecialForms.html#%3C%3C%3E...

Rendello

Erlang's bitstring/binary handling is one of those things that once you use, you'll wonder why it's not in every language (alongside, for me, Rust's enum/sum types and Python's badly-named but wonderfully useful while-else).

tikhonj

OCaml also has a binary string pattern matching feature which sounds pretty similar: https://practicalocaml.com/parsing-with-binary-string-patter...

schultzer

Elixir compiler is written in Erlang, Erlang can produce very efficient code, the new json library can beat c libraries at decoding / encoding. And you get this with a strongly typed dynamic language, which is a distributed language. It’s really hard to beat the BEAM, if only we had better number crunching, but in so cases you can always write a nif.

dcsommer

"Strongly typed" is stretching it. Type checking is bolted on and not part of `erlc`. Typing is quite unergonomic in Erlang/Elixir (similar to Typescript bolted onto JS).

The type system is one of the weakest parts of the beam ecosystem.

cess11

You probably don't, Numerical Elixir/Nx has been out for years and did the NIF:ing for you.

It's one part of why it's quite convenient to juggle ML and LLM tasks on the BEAM, and easy enough that I can manage it.

https://github.com/elixir-nx

troupo

I wish articles like this had more meat on why BEAM is good.

You have to say why it's good. E.g. https://news.ycombinator.com/item?id=28015852

idahoduncan

The Strand programming book states that an early version of the Erlang runtime was implemented in Strand (see "13.1: History" http://www.call-with-current-continuation.org/files/strand-b...), which is an interesting tidbit that I haven't seen come up when the history of Erlang is discussed, like in the featured article.

xelxebar

Studying the BEAM is definitely on my ToDo list. It's task parallelism sounds exemplar, and I really want to understand the architectural ramifications of choosing fine-grained task parallelism vs. a data parallel-friendly approach.

monkfish328

Love beam

I just wish elixir had static typing built in :)

arrowsmith

Give Elixir a try anyway, you might be surprised:

https://arrowsmithlabs.com/blog/you-might-not-need-gradual-t...

Taikonerd

Then you'll love Gleam -- it's a BEAM language with static typing!

https://gleam.run/

brandonpollack2

If only there was a typed language that didn't hand wave serialization

mrkeen

I don't think we'll ever do better than 'IO is made out of bytes'.

kimi

Like Java?

kristel100

It’s fascinating how long the BEAM has lasted. And even more fascinating how relevant its concurrency model still is in today’s async-heavy world. Built different.