BEAM There, Done That

Every secure connection made from an Erlang, Elixir, or Gleam application runs through code she wrote. Most developers have never heard her name.
Ingela Andin has spent more than two decades on the OTP team at Ericsson, maintaining the TLS stack — the piece of infrastructure underneath HTTPS, LDAP, SMTP, and every other secure protocol in the BEAM ecosystem. She is the first point of contact when an AI-generated vulnerability report lands in the OTP inbox. And this year, that inbox changed entirely.
At the start of 2026, maintainers were still laughing at AI bug reports. Daniel Stenberg, creator of Curl, shut down his bug bounty because the reports were hallucinating junk. Then in the space of weeks, the table turned. The reports became real and they kept coming. Linus Torvalds called the kernel security list almost entirely unmanageable. The BEAM did not escape.
Topics include:
* what separates a vulnerability from a bug — and what separates a bug from someone doing something dumb
* what Ingela's inbox looked like at the start of 2026 and what it looks like now
* what a hallucinated AI vulnerability report actually looks like — the asymmetry example that sounded serious and wasn't
* why the domain knowledge of the person running the scanner matters more than the scanner itself
* how the OTP team triages reports: domain knowledge first, then AI agents to help narrow it down, then human verification
* the full fix pipeline: from GitHub advisory to coordinated patch release across three maintained OTP versions to CNA publication
* what happens when a bug fix has a bug — and why that's more embarrassing than a partial fix
* property-based testing as the tool the team uses to stop bugs from coming back
* the one thing Ingela wishes every developer understood before filing a report: write the reproduction case in Erlang, include the full crash report, and don't leave details out
* what companies depending on OTP can actually do to help — starting with the "Help Wanted" label on GitHub
Companion episodes: BEAM Security Wake-Up Call with Jonathan Machen and Peter Ullrich; Bruce Tate on AI, juniors, and coding agents.
Recorded October 1, 2026.

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

The Navajo Nation inside Arizona observes daylight saving. The Hopi reservation inside the Navajo Nation skips it again. There's a corner of the Yucatan Peninsula that takes 20 minutes to drive through and costs you an hour on your sat nav. No compiler warns you about any of this.
Kip Cole has spent 10 years building the Elixir libraries that handle what software gets wrong about human reality: localization, time, and scheduling. CLDR/ex_cldr gave the ecosystem 173,000 Unicode characters and locale-aware formatting for numbers, dates, currencies, and units. Tempo remodelled time as an interval instead of an instant. And this week, Agenda shipped - the scheduling engine four years in the making.
Topics include:
why localization is not translation - the three things that go wrong in an e-commerce search before a single word has been mistranslated

the 10-year weekend project: how a localization library for Elixir turned into 28 packages and a full rewrite into Localized

why compile-time code generation with Elixir macros hit a wall - 1,000+ function clauses and quadratic compile times - and why moving to runtime fixed it

the astronomical algorithms scar: three years of learning a new branch of mathematics to implement calendar software the BEAM was never designed for

what Tempo makes explicit that everyone does by accident: time as an interval, not an instant

why scheduling is just set intersection over everyone's free and busy intervals - and why that single insight collapses almost every hard scheduling problem

how "sometime on Tuesday" is not a time but a domain error - and what Tempo forces you to say instead

Unicode version 18, 173,000 human language characters, and why most language ecosystems still can't represent them correctly

the difference between CLDR (the Unicode standard) and Localized (the Elixir implementation of it)

what Agenda actually ships this week and what's next

Recorded September 8th, 2026.

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

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