Coding Chats episode 74 - Erik Stenman talks to John Crickett about the BEAM virtual machine — the runtime behind Erlang, Elixir, and Gleam. Built by Ericsson in the 1980s for telephone switches, it was designed for fault tolerance and concurrency from day one, yet never achieved mainstream popularity despite being technically superior to many alternatives.

The discussion covers what makes BEAM unique: lightweight isolated processes, a "let it crash" fault philosophy, and powerful built-in introspection. Erik also shares practical lessons from production use and explains why newer languages like Elixir and Gleam are finally bringing BEAM the attention it deserves.

Chapters

00:00 Introduction to Beam and Erlang

02:45 The Unique Features of Erlang and Beam

05:17 Concurrency and Fault Tolerance in Beam

07:34 Applications and Use Cases of Erlang

10:00 Error Handling and Process Supervision

12:49 Performance Considerations in Beam

15:09 Learning and Adopting Erlang and Elixir

17:28 The Future of Erlang, Elixir, and Gleam

37:04 Exploring Related Content

Erik's Links:

https://happihacking.com/ https://happihacking.com/blog/

https://github.com/happi/theBeamBook

https://www.amazon.com/dp/9153142535https://www.elixirconf.eu/trainings/the-beam-for-developers/

John's Links:

John's LinkedIn: https://www.linkedin.com/in/johncrickett/

John’s YouTube: https://www.youtube.com/@johncrickett

John's Twitter: https://x.com/johncrickett

John's Bluesky: https://bsky.app/profile/johncrickett.bsky.social

Check out John's software engineering related newsletters: Coding Challenges: https://codingchallenges.substack.com/ which shares real-world project ideas that you can use to level up your coding skills.

Developing Skills: https://read.developingskills.fyi/ covering everything from system design to soft skills, helping them progress their career from junior to staff+ or for those that want onto a management track.

Takeaways

BEAM was built for telephone switches in the 1980s — its reliability features translate surprisingly well to modern web and distributed systems.

Erlang lost the popularity race to Java largely due to marketing, not technical merit.

BEAM processes are extremely lightweight — hundreds of bytes, not kilobytes — allowing millions to run concurrently.

"Let it crash" is a design philosophy, not laziness — isolating failures prevents one bad process from taking down the whole system.

No shared memory between processes eliminates an entire class of concurrency bugs.

Per-process garbage collection means no "stop the world" pauses like you get in Java.

Hot code loading lets you upgrade a running system without downtime — but it requires careful thought about data structure changes.

BEAM's built-in introspection lets you inspect a live system in real time, making debugging far faster.

Elixir and Gleam are modernising the syntax and bringing new developers onto the BEAM platform.

BEAM doesn't solve everything — good architecture still matters, but it gets you there faster than most alternatives.