BEAM There, Done That

Plangora

BEAM There, Done That is a podcast about building real systems with Elixir, Erlang, and the BEAM. We’ve built it before — distributed systems, fault‑tolerant services, event pipelines, real‑time apps, production nightmares, and the supervision trees that saved them. Each episode dives into practical lessons from shipping software on the BEAM: architecture decisions, scaling challenges, operational failures, and the patterns that actually work. No hype. No theory without scars. Just hard‑won experience from engineers who’ve been there.

  1. Static Types Finally Come to the BEAM | Annette Bieniusa & Guillaume Duboc

    -6 дн.

    Static Types Finally Come to the BEAM | Annette Bieniusa & Guillaume Duboc

    Joe Armstrong once said anyone can write a type system covering 90% of Erlang — it's the remaining 10% that defeats even the brightest minds in computer science. He was referring to Philip Wadler. That was 1995. Thirty years later, the BEAM is finally converging on an answer. In this episode, Alan Wyma and Francesco Cesarini sit down with Annette Bieniusa, professor of software technology at RPTU Germany, and Guillaume Dubois, PhD from IRIF Paris now at Dashbit, to dig into what it actually takes to bring static types to Erlang and Elixir — and why it took this long. Topics include: why every serious attempt at typing Erlang since 1995 — soft types, subtyping, Dialyzer — ran into the same wall, and what's genuinely different now what set-theoretic types are and why they're the foundation Elixir 1.2's type system is built on how Elixir's gradual type system differs fundamentally from TypeScript or Python's approach — and why baking dynamic in from the start changes everything why the BEAM ran telecoms for 25 years without static types, and what problems types are now actually solving the risk nobody talks about: developers getting lulled into false confidence by type checking, writing fewer supervision trees and less defensive code how Annette's parallel etalizer for Erlang and Guillaume's Elixir work share the same theoretical foundation but make different design choices why "type systems don't mean error-free" — and what types actually buy you on the BEAM specifically what Elixir 1.2 ships, what's still being worked on, and the one thing you can do this week Recorded May 28, 2026.

    1 ч. 3 мин.
  2. 30 Years Inside the BEAM: Björn Gustafsson on Building Erlang's Runtime

    26 июн.

    30 Years Inside the BEAM: Björn Gustafsson on Building Erlang's Runtime

    Three engineers. Three different virtual machines. One conversation that started with the JAM and ends with the JIT compiler. Allen Wyma and Francesco Cesarini sit down again with Björn Gustafsson — member of the OTP team since 1996, and the person who has personally shepherded the BEAM through every major transition since taking it over from Bogdan Wódzicki — for a deep dive into 30 years of runtime engineering. Topics include: the three competing virtual machines built in parallel at Ericsson's lab — JAM, Robert Virding's V, and Bogdan's BEAM — and why each one's design choices succeeded or failed a compiler bug that caused random crashes and took weeks to find — and the BEAM Validator that was built specifically so it could never happen again why "turbo Erlang" compiled-to-C delivered a 10-20x sequential speedup on paper that shrank to 2x once concurrency entered the picture, and why that mattered for chip design the BEAM loader — Björn's own invention, still in use today — and why decoupling the compiler from hand-written runtime translation mattered how Björn took over Bogdan's code in 1997 and turned a research prototype into a 30-year production runtime without ever breaking backward compatibility what's coming next: the JIT compiler (next episode), type systems, and a possible episode on the historical and emerging Erlang machines -record(history, { jam, v, turbo_erlang, beam }). If you care about language runtimes, VM design, or how production systems survive three decades of evolution without ever stopping, this episode is for you. Recorded May 26, 2026.

    53 мин.
  3. Why Elixir Beat Go and Rust for BlueSky's Data Plane | Chris Beck

    19 июн.

    Why Elixir Beat Go and Rust for BlueSky's Data Plane | Chris Beck

    There's a gap between BlueSky's open reference implementation (handles a few hundred thousand users) and BlueSky's own production system (handles millions, but runs on infrastructure most teams can't replicate). Chris Beck and his team at Bitcrowd set out to close it -and ended up somewhere they didn't expect. In this episode, Allen Wyma and Francesco Cesarini talk to Chris Beck, founder of Bitcrowd in Berlin, about building an open source alternative to BlueSky's data plane -the component that turns the AT Protocol firehose into the timeline you actually scroll through. This is the third episode in our "right tool for the job" series, following Rust and Zig. Topics include: what the AT Protocol actually is, and why it's closer to an "operating system for social apps" than a single product why BlueSky's own production solution (similar to Discord's MongoDB → Cassandra → ScyllaDB journey) is out of reach for smaller communities the real numbers: 200-500 messages/second on a normal day, 6 million active users during the November 2024 US election the hot path vs. cold path split that shaped the entire architecture why Go, Rust, and Node were all evaluated and rejected -including why Node's single-threaded event loop was already a dead end for the BlueSky team themselves why Elixir wasn't the expected choice, and what ETS gave them for free that they'd have had to hand-build everywhere else using a Rust NIF via Rustler for roaring bitmaps to solve the "social proof" (mutual follows) feature -and what that NIF actually costs in terms of crash isolation why losing almost every microbenchmark didn't matter once they asked "do we actually need to go there?" the fan-out architecture that pushes messages directly into user mailboxes, and why that made backpressure a non-issue what's left to build, and the one sentence Chris wants every team picking a stack to remember Recorded June 15, 2026.

    41 мин.
  4. Why Multiplayer Games Are Just Distributed Systems | Ellyse Cedeno on BEAM & the Actor Model

    12 июн.

    Why Multiplayer Games Are Just Distributed Systems | Ellyse Cedeno on BEAM & the Actor Model

    Every player is a process. Every monster is a process. Every zone is a process. Sound familiar? In this episode, Allen Wyma and Francesco Cesarini sit down with Ellyse Cedeno - technology and product leader with 25+ years across online games, distributed systems, and real-time platforms - to explore why the BEAM and the actor model are a natural fit for multiplayer game servers, and why the games industry keeps learning this the hard way. Topics include: why MMORPGs and telecom systems have more in common than most people realize the N-squared problem: why high player density is so expensive and how classic games solved it why Java threads and deadlocks were the original game server nightmare how the actor model eliminates lock management - and what that means for mob AI event-sourced vs tick-based architecture and when each makes sense zones, sharding, and the air traffic control analogy for seamless server handoffs building a NetHack-style multiplayer game in LiveView - and what the DOM diffing taught her about game state why the games industry is dominated by C++ and Unreal, and what it would take to change that using player behavior analytics to catch bugs before ops teams or server logs do the production horror story of someone pulling the live database drive mid-operation Plus: why Ellyse wants to publish a 100% Elixir game on Steam, and what the open source game_server project on Codeberg is trying to do. Recorded May 25, 2026.

    1 ч. 7 мин.
  5. Who Builds the Next Generation of Senior Devs? Bruce Tate on AI, Juniors, and the Career Path Crisis

    5 июн.

    Who Builds the Next Generation of Senior Devs? Bruce Tate on AI, Juniors, and the Career Path Crisis

    The dashboards are green. PRs are shipping faster than ever. So why are seniors quietly burning out — and juniors not actually learning? In this episode, Allen Wyma and Francesco Cesarini sit down in person with Bruce Tate — author of Seven Languages in Seven Weeks, co-author of 10+ books on Elixir, and founder of Groxio — who just shut down a 10-year mentoring organization because the junior developer career path had become too unclear to sustain. Topics include: why AI has broken the traditional apprenticeship model without replacing it three scenes from a Tuesday afternoon: Freddie the junior, Martin the senior, and the manager watching the green dashboard — what each is missing about the other two the five modes of AI-assisted coding (completion, mini tasks, debugging, collaboration, vibing) and which ones a junior should actually live in why the pull request is no longer a learning moment — and what to do instead the four things a junior must develop to become a senior in 2026 what leadership owes the next generation, and the one pledge every team should make where BEAM languages fit in all of this — and why Elixir may be the best language for AI-assisted development The productivity dividend is real. The question is whether we invest it or eat it. Resources mentioned: Groxio: grox.io Tidewave Ash Framework "Tell Me a Story" talk by Sasha (referenced in episode) Recorded May 18, 2026.

    1 ч. 7 мин.
  6. AI Found 5 CVEs in One Afternoon — The BEAM Security Wake-Up Call | Peter Ullrich & Jonathan Machen

    29 мая

    AI Found 5 CVEs in One Afternoon — The BEAM Security Wake-Up Call | Peter Ullrich & Jonathan Machen

    The BEAM ecosystem spent decades flying under the radar - too niche to attract serious attackers. That era is over. In this episode, we sit down with Peter Ullrich, the developer who ran a $10 experiment at ElixirConf EU in Málaga and discovered a vulnerability that could crash the BEAM with a 13-character string - with zero prior security experience. Then we hear from Jonathan Machen, CISO of the Erlang Ecosystem Foundation, whose job is to catch and coordinate everything Peter finds. We cover: How Peter built a simple bash script that scanned the most-downloaded Hex packages - and what he found Why LLMs have changed the cost and skill floor for vulnerability research forever The CVE disclosure process: what happens from the moment a bug is found to the moment it's published How the EEF's CNA went from 9 CVEs in a year to more in a single week What library maintainers should do right now (spoiler: it's three clicks on GitHub) The AGES initiative, supply chain security, and the gap between what's been built and what the moment demands Why paying a vendor like Trivy isn't enough - and what actually needs to happen If you run Phoenix in production, this episode is required listening. Resources mentioned: Peter's blog post and prompts: github.com/pultrich (linked in post) Linux Foundation's Scrutineer project Report vulnerabilities: cna@erlef.org Support the Erlang Ecosystem Foundation: erlef.org

    1 ч. 2 мин.
  7. Inside the BEAM: Björn Gustavsson on Maps, Records, and Runtime Design

    22 мая

    Inside the BEAM: Björn Gustavsson on Maps, Records, and Runtime Design

    For the first time in over a decade, the Erlang runtime is gaining a new native data type — and on this episode of BEAM There, Done That, hosts Francesco Cesarini and Allan Wyma sit down with Björn Gustavsson, known by many as the “B” in BEAM. Björn takes listeners deep into the history of records, maps, tag bits, and the architectural trade-offs that shaped the Erlang runtime from the 1990s to today. The discussion explores why records were originally implemented as a hack, why maps never fully replaced them, and what finally made native records possible after nearly 30 years. Along the way, the episode becomes a rare tour through BEAM internals, compiler design, runtime tagging, and the practical realities of evolving a production VM used at massive scale. If you care about language design, runtime systems, or the history and future of Erlang/OTP, this is one of the deepest technical conversations the podcast has released.

    55 мин.
  8. Inside Phoenix: A Plug, a Macro, and What You Need to Know To Build Your Own Framework

    15 мая

    Inside Phoenix: A Plug, a Macro, and What You Need to Know To Build Your Own Framework

    Three and a half years, one book, and a clearer answer to what Phoenix is actually doing under the hood. Phoenix makes building web apps in Elixir feel effortless, but how much of that is genuine elegance and how much is metaprogramming hiding the complexity? Adi Iyengar spent three and a half years writing Build Your Own Web Framework in Elixir to find out, and in this episode he sits down with Francesco and Allen to share what he learned by rebuilding Phoenix from the ground up. We dig into Plug as the real heart of the framework, when metaprogramming is the right tool and when it quietly becomes a liability, and why understanding the layers underneath Phoenix is what separates a productive developer from a senior one. Along the way Francesco brings out the BEAM web-server history most listeners have never heard — Yaws, Bluetail, Mochiweb, Inets — and the conversation lands on what coding agents get wrong about Phoenix in 2026.

    1 ч. 2 мин.
См. все (18)

Об этом подкасте

BEAM There, Done That is a podcast about building real systems with Elixir, Erlang, and the BEAM. We’ve built it before — distributed systems, fault‑tolerant services, event pipelines, real‑time apps, production nightmares, and the supervision trees that saved them. Each episode dives into practical lessons from shipping software on the BEAM: architecture decisions, scaling challenges, operational failures, and the patterns that actually work. No hype. No theory without scars. Just hard‑won experience from engineers who’ve been there.

Информация

  • Автор
    Plangora
  • Годы выхода
    2 тыс.
  • Выпуски
    18
  • Ограничения
    Без ненормативной лексики
  • Авторские права
    © Plangora
  • Сайт подкаста
    BEAM There, Done That

Вам может также понравиться