LT | An OTP Bug That Slept for 16 Years - Albert Schimpf | Code BEAM Europe 2025

CodeSync · November 19, 2025, 2:00pm

This lightning talk was recorded at Code BEAM Europe in November 2025. If you’re curious about our upcoming event, check https://codebebeameurope.com

How do you find a bug that’s been sleeping in production since 2008? With Etylizer and the power of set-theoretic types. We present our recent research advances in static analysis for Erlang, which has recently allowed Etylizer to scale to the analysis of mature codebases like the Erlang/OTP standard library. Etylizer doesn’t just spot type spec inconsistencies—it hunts down hidden crash conditions. We’ll demonstrate our research progress by showcasing how it found a crash-inducing type specification inconsistency in the Erlang standard library, hidden in (plain?) sight for 16 years, proving that no code is too old to be made safer.

Let’s keep in touch!

Comments welcome! View the code-sync tag for more Code Sync talks!

keyhan · November 26, 2025, 5:48am

IMO this might not be a bug at all, but rather intentional Erlang design. The “fix” could actually be introducing unnecessary defensive programming that goes against Erlang’s philosophy of letting processes crash on invalid states, it is normal behaviour of erlang.

Erlang Philosophy Perspective

In Erlang, it’s often intentional and correct for functions to crash with bad inputs rather than return false. The philosophy is:

Crash fast on invalid inputs
Let supervisors handle errors
Don’t mask programming errors with defensive coding

When Crashing is Preferred

Crashing might be better if:

Improper lists indicate serious programming errors
The function should only handle proper data structures
The crash provides a clearer signal than silent false
Supervisors will restart the process appropriately

code-sync