Elixir's dynamic fans get types — and the compiler immediately finds their bugs

A dynamic language quietly grows a type checker

Elixir spent years as the language whose fans swore you didn't need static types — pattern matching and the BEAM virtual machine made up for it. Then the v1.20 release landed on the front page with the opposite pitch: it is now a gradually typed language, and the thread is full of converts watching the compiler find bugs they didn't know they had.

Types with zero annotations, and a dynamic() that isn't any()

The headline is that v1.20 performs type inference and checking across all Elixir programs without requiring a single annotation, surfacing dead code and "verified bugs" — typing violations guaranteed to fail at runtime. The design hinges on a gradual type called dynamic() — a placeholder for not-yet-known types — with two properties the release stresses, compatibility and narrowing: it tags uncertain values like dynamic(integer() or binary()) and only screams when the supplied and accepted types are completely disjoint. Inference now flows through guard clauses with unions and negations (is_list(x) and is_integer(y)), pattern matching that refines ({:ok, x} = y), is_map_key/2 checks, and case-clause narrowing that prunes redundant branches. The release reports passing 12 of 13 categories on the "If T" type-narrowing benchmark. Type signatures themselves are still deferred, pending recursive and parametric types.

The free-bugs crowd, and a jab at the old orthodoxy

The reaction from working Elixir shops was less about theory than about the upgrade experience:

"I love the fact that I can upgrade my elixir version and the compiler finds a bunch of free bugs. The last several releases have been like this, and basically no breaking changes." — a developer congratulating the team

Not everyone let the community off the hook for its previous stance:

"critics were saying, it needs typing, and all the elixir fans were saying you don't need typing … now they get typing and it finds bugs for them … but you said you didn't need that to prevent bugs?" — a developer who'd tried Elixir but balked at the lack of types

A ten-year veteran tempered the hype with a real question about whether this beats the old tooling:

"I would love to know how the state of what's in v1.20 compares to un-spec'ed dialyzer … I haven't found dialyzer terribly useful." — a Senior Software Engineer using Elixir professionally for ~10 years

The most interesting claim came from a commenter looking past gradual typing to what arrives when annotations ship:

"Elixir will apparently be the first somewhat notable language that supports full set theoretic types … TypeScript and Scala only support … union and intersection … {union, intersection} is not functionally complete, while {union, intersection, complement} is." — a commenter citing functional completeness

The upgrade that audits you

The quiet trick here is that this isn't an opt-in feature you migrate to — it runs on existing code and reports back. A language community that built its identity on not needing types just shipped a checker that, on first compile, tells everyone exactly how much it was costing them. The set-theoretic ambition is the longer game: complement types would let Elixir express constraints TypeScript structurally can't, which is a strange sentence to write about the language that used to be the dynamic-typing holdout.