Show Notes
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.
More from Coding Chats
Coding Chats Episode 83 - In this episode, VB from OpenAI’s developer experience team explains why he thinks plan mode is obsolete and how coding agents have shifted from step-by-step instructions to outcome-driven, long-running work. We cover how to write a good agents.md, why tests still matter when agents write the code, spec-driven development, and why cloud agents may be the future of dev tooling.
Coding Chats Episode 82 - John talks with Dave Westgarth, head of delivery at a Databricks consultancy. Dave shares his path from a psychology degree and McDonald's into tech, and they discuss why the Scrum Master role is so misunderstood, how it differs from a delivery manager, and whether either needs to be technical.They also look at how AI is changing delivery work. Faster code just moves the bottleneck upstream, John argues there's no AI-specific skill you can't learn in a day, and engineering fundamentals are what make AI useful.
Coding Chats Episode 81 - Ben Howdle talks to John Crickett about being a first time CTO in a start-up. Ben, author of The First CTO, shares what changes when you move from building technology to leading a technical team: the pressure, the trade-offs, and the realization that writing code is only part of the job.Drawing on startup experience and lessons learned the hard way, Ben discusses how to balance quality against runway, manage people, and communicate technical decisions in terms that founders and other non-technical stakeholders can understand. He also explores why resourcefulness, resilience, and comfort with ambiguity matter so much—and why CTOs often spend more time selling ideas than they expect.Whether you’re stepping into your first CTO role or leading a technical team at an early-stage company, this conversation offers candid insights into the realities of technical leadership.
Coding Chats Episode 80 - start-up advisor Alexander Berkovich shares his expertise on building successful start-ups, hiring strategies, CTO roles, and the importance of communication between technical and business teams. Discover practical tips for navigating the challenges of early-stage companies and how to align technical excellence with business goals.
Coding Chats Episode 79 - Richmond Alake, Director of AI Developer Experience at Oracle, joins John to discuss agent memory — how AI agents store, retrieve, and adapt to information. He argues that developers building memory on flat files are naively reinventing the database, and that once you factor in concurrency, security, and scalability, a proper database is inevitable. The conversation covers the full memory stack and how Oracle's AI database keeps embeddings and data together without shipping sensitive information to external providers.