BEAM There, Done That

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.

BEAM There, Done That is a technology podcast hosted by Plangora, with 30 episodes on record and a Required Pod Score of 80.

Plangora hosts BEAM There, Done That, a technology show with 30 episodes published.

Our AI reads these to draft pitches. Use them as grounding for a pitch that cites a real guest and a specific topic.

• 

  Episode #31

  Alex Koutmos on Elixir for Finance, Trading & Blockchain

  Oct 2, 20261h 3mS1

  Brex runs on Elixir. Klarna runs on Erlang. Mastercard is believed to use it. And most of the community that builds on these systems watches them with PromEx - a library written by today's guest. Alex Koutmos has been in the Elixir ecosystem for over a decade. He wrote PromEx - the Prometheus metrics library most of this audience runs in production - and he's just written Elixir for Finance with his brother Dimitrios, a tenured finance professor at Texas A&M. The book takes Livebook, Explorer, NX, and Scholar and points them straight at markets, trading strategies, and blockchain infrastructure. Topics include: why switching money and routing a stock order are the same problem as switching a phone call - and why the BEAM was built for both the ISO 8583 protocol story: 100 lines of C per message frame, dropped to 10 in pure Erlang, dropped to 4 with the bit syntax - and why nobody talks about this Explorer as an Elixir wrapper around Polars (a Rust data frame library) - why the BEAM delegates the heavy compute and keeps the orchestration how to use Livebook, NX, and Scholar to backtest a moving average crossover trading strategy without leaving Elixir why "let it crash" doesn't mean "let the money vanish" - and exactly how a ledger, Oban, and durable event storage keep the truth safe across process restarts the difference between a ledger and a database - and why a bank built on plain Postgres misses the point blockchain as a distributed ledger: the same distributed state problem the BEAM community was chewing on long before Bitcoin existed why fintech companies use Erlang and Elixir as a competitive advantage - and tell nobody BlockScout, Aeternity, and where BEAM languages already run in blockchain infrastructure what the Python and JVM financial tooling stacks miss that Explorer and NX cover - and where they still win Recorded August/September 2026. Resources mentioned: Elixir for Finance - the book PromEx on Hex BlockScout - open source Ethereum explorer written in Elixir Aeternity - blockchain built in Erlang

  ListenShow Notes
• 

  Episode #29

  Is Your Elixir Code Actually Fast? Tobias Pfeiffer on Benchmarking

  Sep 18, 20261h 11mS1

  Everyone has an opinion about whether the BEAM is fast or slow. Almost nobody has actually measured it properly. Tobias Pfeiffer -PragTob on the internet, benchmarking nerd, real-time engineer at Supabase -came to Elixir from Ruby because Ruby couldn't handle WebSockets at scale. Then he learned the language the way he learns every language: by building a benchmarking library. Ten years later, Benchee is what most of the Erlang and Elixir world reaches for when it wants a number instead of an argument. Topics include: why Tobias writes a benchmarking library every time he learns a new language -and what that discipline actually teaches about how a runtime works the production scar: a benchmark that showed one query was faster, deployed it, and discovered the benchmark had been measuring the wrong input entirely the single most important insight about benchmarking: most people quietly fool themselves and walk away more confident and more wrong than when they started inputs as a first-class feature -the lesson José Valim taught Tobias within 17 minutes of an open GitHub issue why body-recursive map is faster than tail-recursive map for small lists on the BEAM -and what that tells you about the runtime what reductions are, why they're a more stable measurement than wall time, and when they diverge how Benchee measures memory: spawning a monitored process, watching GC events, reporting exact bytes -and why deterministic code gives deterministic memory the JSON benchmarking arms race -built-in OTP JSON, jason, Jiffy, and why comparison benchmarks usually miss the point why Benchee has no macros, no DSL, and deliberately only uses functions -and why that design decision made it composable in ways nobody predicted the hardest benchmarking mistake to stop making: confusing latency and throughput what Toby wishes more Elixir developers understood about BEAM performance before they opened a PR claiming something was faster Recorded August 21, 2026. Resources mentioned: Benchee on Hex: hex.pm/packages/benchee Benchee HTML formatter -self-contained HTML output with downloadable graphs Benchee markdown formatter PragTob on GitHub: github.com/bencheeorg

  ListenShow Notes
• 

  Episode #28

  Louis Pilfold on Building Gleam - Static Types on the BEAM

  Sep 11, 20261h 12mS1

  What if the BEAM had a language that felt like talking to a friend instead of fighting a compiler? That's the problem Louis Pilfold set out to solve. He loved the BEAM. He missed static types. Every other option was a tradeoff he couldn't live with. So he built Gleam - and after years of quietly saying no to everything he wasn't sure about, it's gathered a community, found production users, and now runs on servers, browsers, and $2 microcontrollers. Topics include: why every successful language is born from a problem - and what specific frustration made Louis start building rather than just complaining the discipline of saying no: no if, no currying, no pretending two targets are one world the design decision Louis regrets most - the conditional compilation syntax he's now stuck with and desperately doesn't want more people to use why Gleam's concurrency model lives in a library rather than the language - and what that buys in terms of flexibility when smarter people eventually improve it how Gleam solved the problem everyone said was unsolvable: "you can't type message passing on the BEAM" what the JavaScript and BEAM targets share and where they genuinely can't be unified - and why pretending they can leads to terrible architecture why Gleam chose Erlang records as its data structure and what that costs at runtime Lustre, Gleam's web framework - beating mainstream JavaScript frameworks in benchmarks while written entirely in Gleam how Louis funds his work on Gleam: GitHub Sponsors, the Gleam community, and what sustainable open source actually looks like from the inside what Gleam will look like in 3–5 years - native records, better JavaScript interop, and why the language's approach to stability makes those changes possible Recorded August 20, 2026. Resources mentioned: gleam.run - docs, tour, community tour.gleam.run - interactive language tour running the Gleam compiler compiled to Wasm, takes an afternoon Exercism Gleam track Code Crafters - build Redis/SQLite/Git in Gleam GitHub Sponsors: lpil (Louis Pilfold) Lustre - Gleam's web framework

  ListenShow Notes
• 

  Episode #27

  How WhatsApp Fixed Erlang's Tooling Problem | Roberto Aloi & Michał Muskała

  Sep 4, 202637 minS1

  Part one established that Erlang scales. Part two is about what comes after - keeping a codebase that large healthy for years, when most engineers arrive having never written Erlang before. WhatsApp's answer was to invest in the language itself. The formatter, the language server, the type checker. And then to open source almost all of it back to the community - not as charity, but because diverse use cases and external bug reports make the tools better. Roberto Aloi and Michał Muskała are back for the half that doesn't appear on conference posters. Topics include: why the investment in tooling came from a developer survey rather than an engineering instinct - the data showed Erlang developer experience was the weak point what ELP (the Erlang Language Platform) actually is and how it superseded the Erlang LS that Roberto built before joining WhatsApp how eqWAlizer, WhatsApp's type checker, was rolled out without breaking other teams - the team owning the type checker also owned the task of fixing things up when new checks introduced errors why types and let it crash aren't in tension: you can never statically verify everything in a dynamic language, so the gap is where supervision and recovery fit the two biggest misconceptions about static analysis tools: that they're slow (modern tooling is fast) and that you have to commit to them all at once (you can do it incrementally) why WhatsApp open sources tools that took significant engineering investment - keeping them internal would make them worse, not better what's still unsolved: exhaustiveness checks at this scale remain an open problem how AI is changing the Erlang learning experience - build first, ask AI to review your patterns afterward the word that ties both episodes together: trust. Supervision earns it at runtime. Types earn it at compile time. Companion episode: Part 1 on scale and operations. Recorded June 25, 2026.

  ListenShow Notes
• 

  Episode #26

  Inside WhatsApp with Roberto Aloi & Michał Muskała

  Aug 28, 202635 minS1

  Everyone quotes WhatsApp when the topic of Erlang and scale comes up. Fewer people know what it actually looks like from the inside - what was hard, what was never hard, and what the team spent their time on once the concurrency stopped being the problem. Roberto Aloi and Michał Muskała work on the team keeping it running. This is the first of two episodes with them. Topics include: what Roberto's first Erlang moment was - implementing a GenServer for a robot at university and learning binary pattern matching felt like cheating why Michał came to Erlang backwards, from Elixir, and what the tooling gap actually felt like the column numbers OTP bug that caused cascading failures and taught Roberto what no documentation could the optimization that made the JSON Unicode parser slower - binary pattern matching was the wrong tool, and a custom state machine was faster what "let it crash" actually means at WhatsApp scale: letting it crash is the easy part, recovery is where the engineering lives why the 30th employee was the first person at WhatsApp with Erlang experience - and what that means for hiring the most misunderstood thing about Erlang at WhatsApp: scaling isn't the exotic part, keeping the codebase healthy is how WhatsApp does deployments: 1% of servers first, one region next, monitoring throughout, ready to roll back what types of failures become normal at this scale - and why disaster recovery drills are a regular practice overly dynamic code as the anti-pattern that creates the most sustained pain Part two covers ELP, Equalizer, and the tooling that keeps a codebase this large navigable. You want both. Recorded June 25, 2026.

  ListenShow Notes

Recent guests on BEAM There, Done That. Study who booked and why before you pitch.

Based on semantic analysis of episode topics and host coverage, this show is a strong guest fit for executives in:

Industry fit is computed by PitchCentric using vector embeddings of the show's episode catalog.