Elixir v1.20: Now a gradually typed language

Original Article ↗ Hacker News Discussion ↗

Elixir 1.20 introduces a gradual, set-theoretic type system that promises static checking without changing runtime behavior, reigniting interest in the language among developers who previously avoided it over typing concerns. Commenters weigh the benefits of stronger types—fewer bugs, better tooling, and improved AI-assisted coding—against Elixir’s existing strengths in fault-tolerant concurrency, pattern matching, and ecosystem stability. The thread also surfaces ongoing pain points such as Phoenix/LiveView’s learning curve, debugging ergonomics, and limited job markets, while comparing Elixir’s direction to alternatives like Gleam, Rust, and OCaml.

Overview of Elixir 1.20’s gradual typing

  • Gradual type system is based on “strong arrows” and set-theoretic types (unions, intersections, negations).
  • No new surface syntax yet; it infers types from existing constructs (pattern matching, guards).
  • Design goal: soundness without runtime casts at typed/untyped boundaries. Generated bytecode is semantically identical to untyped code, so asymptotic complexity is unchanged.
  • Future annotations are planned; type information can propagate via “strong” functions, at least within a module.

Performance, Dialyzer, and existing tooling

  • Several people report noticeably faster compilation in real projects after upgrading.
  • Dialyzer’s success typing is seen as limited in practice, especially with circular dependencies and protocols; some expect the new system to be more useful.
  • Some still use typespecs mainly for documentation; compiler has increasingly caught issues before Dialyzer anyway.

Dynamic vs static typing debate

  • Many are enthusiastic: types find real bugs “for free”, improve confidence in large codebases, and may help AI agents via better constraints and error feedback.
  • Others argue Elixir/BEAM’s fault-tolerance (“let it crash”, supervision trees) already mitigates many runtime errors; they rarely see type errors cause outages.
  • Some see types as a “nice but niche” feature for Elixir; others say lack of static types previously kept them from adopting it seriously.

Learning curve, ergonomics, and security

  • Newcomers report Elixir/Phoenix as powerful but hard to learn: heavy macro use, compile-time magic, optional parentheses, and keyword-list syntax are frequent stumbling blocks.
  • BEAM concepts (processes, supervision, restart strategies) feel overwhelming to some; others share articles and books to bridge this gap.
  • Phoenix LiveView security is debated: some worry about calling arbitrary handlers over hijacked websockets; others stress that any client can send any message and that authorization must be enforced via state and guards, similar to HTTP.

Comparisons and ecosystem

  • Gleam is frequently mentioned: fully statically typed, Rust-like syntax, compiles to BEAM and JS, but lacks macros and Phoenix/Ecto maturity.
  • Some prefer Rust/Go/OCaml for “real” static typing and simpler deployment; others value BEAM’s concurrency and fault-tolerance more.
  • Elixir’s long-term stability and minimal breaking changes are widely praised, though job opportunities are perceived as limited in some regions.