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

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.