
How does Elixir 1.20's type system actually differ from what TypeScript or Dialyzer do - and does the distinction matter in practice?
New BEAM There, Done That with Annette Bieniusa (RPTU, Germany) and Guillaume Duboc (Dashbit, PhD from IRIF Paris) on the theoretical and practical story behind what's shipping in Elixir 1.20.
The episode covers the set-theoretic foundation, the gradual design, and the long history of failed attempts at typing Erlang since 1995. But the thing that stuck with me most was the framing of what the type system is and isn't trying to do:
The BEAM ran telecoms for 25 years without static types, with seconds of downtime per year. Supervision trees and let it crash handle an entirely different class of failures from what a type checker catches. The argument for types here isn't that the runtime is broken - it's that type errors are a separate cost (restarts, latency, overprovisioning) that supervision handles but doesn't eliminate. Even catching 5% of those at compile time instead has measurable infrastructure impact.
What got me thinking: the episode raises the false confidence risk - developers seeing types and writing fewer supervision trees, less defensive code, no recovery strategy. Has anyone here actually observed this shift in teams adopting typed languages? And do you think the BEAM community is more or less susceptible to it than others, given how explicitly OTP teaches you to expect failure?