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 GitHubCompanion 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 boththe 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 thisExplorer as an Elixir wrapper around Polars (a Rust data frame library) - why the BEAM delegates the heavy compute and keeps the orchestrationhow to use Livebook, NX, and Scholar to backtest a moving average crossover trading strategy without leaving Elixirwhy "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 restartsthe difference between a ledger and a database - and why a bank built on plain Postgres misses the pointblockchain as a distributed ledger: the same distributed state problem the BEAM community was chewing on long before Bitcoin existedwhy fintech companies use Erlang and Elixir as a competitive advantage - and tell nobodyBlockScout, Aeternity, and where BEAM languages already run in blockchain infrastructurewhat the Python and JVM financial tooling stacks miss that Explorer and NX cover - and where they still winRecorded August/September 2026.Resources mentioned:Elixir for Finance - the bookPromEx on HexBlockScout - open source Ethereum explorer written in ElixirAeternity - 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 mistranslatedthe 10-year weekend project: how a localization library for Elixir turned into 28 packages and a full rewrite into Localizedwhy compile-time code generation with Elixir macros hit a wall - 1,000+ function clauses and quadratic compile times - and why moving to runtime fixed itthe astronomical algorithms scar: three years of learning a new branch of mathematics to implement calendar software the BEAM was never designed forwhat Tempo makes explicit that everyone does by accident: time as an interval, not an instantwhy scheduling is just set intersection over everyone's free and busy intervals - and why that single insight collapses almost every hard scheduling problemhow "sometime on Tuesday" is not a time but a domain error - and what Tempo forces you to say insteadUnicode version 18, 173,000 human language characters, and why most language ecosystems still can't represent them correctlythe difference between CLDR (the Unicode standard) and Localized (the Elixir implementation of it)what Agenda actually ships this week and what's nextRecorded 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 worksthe production scar: a benchmark that showed one query was faster, deployed it, and discovered the benchmark had been measuring the wrong input entirelythe single most important insight about benchmarking: most people quietly fool themselves and walk away more confident and more wrong than when they startedinputs as a first-class feature -the lesson José Valim taught Tobias within 17 minutes of an open GitHub issuewhy body-recursive map is faster than tail-recursive map for small lists on the BEAM -and what that tells you about the runtimewhat reductions are, why they're a more stable measurement than wall time, and when they divergehow Benchee measures memory: spawning a monitored process, watching GC events, reporting exact bytes -and why deterministic code gives deterministic memorythe JSON benchmarking arms race -built-in OTP JSON, jason, Jiffy, and why comparison benchmarks usually miss the pointwhy Benchee has no macros, no DSL, and deliberately only uses functions -and why that design decision made it composable in ways nobody predictedthe hardest benchmarking mistake to stop making: confusing latency and throughputwhat Toby wishes more Elixir developers understood about BEAM performance before they opened a PR claiming something was fasterRecorded August 21, 2026.Resources mentioned:Benchee on Hex: hex.pm/packages/bencheeBenchee HTML formatter -self-contained HTML output with downloadable graphsBenchee markdown formatterPragTob 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 complainingthe discipline of saying no: no if, no currying, no pretending two targets are one worldthe design decision Louis regrets most - the conditional compilation syntax he's now stuck with and desperately doesn't want more people to usewhy 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 ithow 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 architecturewhy Gleam chose Erlang records as its data structure and what that costs at runtimeLustre, Gleam's web framework - beating mainstream JavaScript frameworks in benchmarks while written entirely in Gleamhow Louis funds his work on Gleam: GitHub Sponsors, the Gleam community, and what sustainable open source actually looks like from the insidewhat Gleam will look like in 3–5 years - native records, better JavaScript interop, and why the language's approach to stability makes those changes possibleRecorded August 20, 2026.Resources mentioned:gleam.run - docs, tour, communitytour.gleam.run - interactive language tour running the Gleam compiler compiled to Wasm, takes an afternoonExercism Gleam trackCode Crafters - build Redis/SQLite/Git in GleamGitHub Sponsors: lpil (Louis Pilfold)Lustre - Gleam's web framework