ElixirConf US 2026 opens Thursday in Chicago, and the dominant theme before a single talk has been given is the Elixir type system. After four years of research, two conference keynotes, and three iterative releases, the graduation from “interesting experiment” to “running in production and catching real bugs” happened quietly in June with Elixir 1.20. The next milestone lands in November with 1.21. If you ship Elixir and have not engaged with the type warnings yet, ElixirConf is the right moment to get serious.
What 1.20 Actually Does #
Elixir 1.20, released June 3, performs whole-program type inference on every language construct without requiring a single annotation. You upgrade, run mix compile, and read what surfaces. That is the entire setup story.
The compiler now understands function signatures, pattern matching, guard conditions, and map key domains well enough to report “verified bugs” — typing violations it can prove will fail at runtime. The false positive rate was a core design constraint: the team would rather miss a bug than nag you with noise. In practice, the compiler passes 12 of the 13 categories in the “If T: Benchmark for Type Narrowing,” the benchmark used to evaluate research-grade type systems. If your project runs Ecto and Phoenix, the major upstream warning fixes are already shipped. An upgrade to 1.20 today is genuinely smooth for most Phoenix applications.
What 1.21 Brings (November 2026) #
The January 2026 roadmap post from the Elixir core team laid out the next 15 months explicitly. The work for 1.21, targeting November, has two headline additions: typed struct field definitions and set-theoretic type signatures for functions.
Typed structs let you define field types directly in defstruct. Today, the compiler can infer that a struct has certain field types based on usage, but it has no authoritative source to verify against. With 1.21, you will be able to declare that :name is a binary() and :age is an integer(), and the compiler will enforce that at every call site.
The function type signatures — the bigger addition — will use set-theoretic syntax rather than Erlang-style @spec. These are additive. Existing code does not break. You adopt them where they add clarity, the compiler enforces them where you declare them, and everything else continues to use inference.
Why Set-Theoretic Types Fit Elixir #
Most developers mental model of a type system comes from either TypeScript (structural nominal types) or Rust (affine static types). Elixir is different in a way that matters for a language built around pattern matching and guards.
Set-theoretic types compose using union (or), intersection ( and), and negation ( not). A function returning either an atom or an integer is expressed as atom() or integer(). A guard that excludes nil narrows the type using negation. Pattern matching on a struct field resolves to an intersection of the incoming type and the pattern constraints. These are the precise operations Elixir code performs at runtime — the type system is describing what the language already does, not imposing a foreign model on top of it.
For comparison: TypeScript explicitly lists “apply a sound or provably correct type system” as a non-goal. Elixir is designed to be sound. That is a meaningful distinction for anyone who has had TypeScript’s any escape hatch cause a production incident.
The @spec Question #
@spec annotations are not going anywhere in 1.21 or 1.22. The Erlang-style typespecs will eventually be moved to a separate library once the set-theoretic type signature system is mature enough to replace them. The roadmap is clear but the timeline is measured in years, not months. Keep your existing @spec declarations; do not invest in writing new ones for the long term.
What to Watch at ElixirConf #
The session to prioritize is “What is New in Elixir Types” by Guillaume Duboc, the primary implementation author behind the type system work. The abstract covers pattern analysis, type tracking, typed structs, and guard analysis — exactly the 1.21 features in preview. The talk will be available online; slides land on the Elixir Forum shortly after.
The Jose Valim and Chris McCord keynotes will set broader direction for the language and Phoenix. Previous ElixirConf keynotes have used the type system work as a case study in Elixir design philosophy: move deliberately, prioritize correctness, and do not break the ecosystem.
What To Do Before the Conference #
Upgrade an existing project to Elixir 1.20 and run mix compile. Read every warning the compiler emits. Most will be real issues worth fixing. A handful may be false positives — report those to the Elixir issue tracker with a reproducible case, as the team actively refines the analysis based on production feedback.
The type system is not a future feature to wait for. It is running in production today, and 1.21 adds the developer-facing syntax that makes it explicit rather than just inferred. ElixirConf US 2026 is where the core team will show where it goes from here.