Elixir 1.17 released: set-theoretic types in patterns, durations, OTP 27

Original Article ↗ Hacker News Discussion ↗

Elixir 1.17 introduces a new set-theoretic, gradual type system and a Duration data type, which many developers see as a major step toward safer, more expressive code without breaking existing projects. Commenters compare Elixir’s upcoming sound type system to TypeScript and Gleam, debate trade-offs in expressivity and performance, and highlight how it builds on BEAM’s strengths like concurrency and powerful REPL tooling. Beyond types, the conversation touches on editor and LSP maturity, LiveView’s prominence versus more traditional Phoenix use, ecosystem gaps such as third-party SDK support, and the language’s appeal relative to more mainstream stacks in terms of productivity and hiring.

Type system & set-theoretic types

  • Strong enthusiasm for the new gradual, set-theoretic type system; people report real bugs already caught in major libraries.
  • Roadmap mentions typed structs as the next milestone.
  • Several comments explain “set-theoretic types” as types-as-sets-of-values with unions/intersections/negations and semantic subtyping.
  • Comparisons to TypeScript: both structural and set-theoretic, but Elixir aims for soundness and uses semantic subtyping and a different approach to gradual typing.
  • Types are checked at compile time; there are no plans for inserting extra runtime checks. The checker reasons about guards the code already has.
  • Debate on soundness vs expressivity; some doubt you can have both fully, but are curious to see how far Elixir gets.

Comparison with Gleam

  • Gleam is described as BEAM + modified Hindley–Milner (HM), with strong inference and simpler, classic static typing.
  • Elixir’s system is seen as more expressive (unions, intersections, negations, gradual typing), likely with higher typing cost.
  • Both type systems run at compile time.

Tooling & editor support

  • Many want a polished JetBrains-style IDE; current VSCode experience is seen as “good but rough,” especially around refactoring and templates.
  • Fragmentation of LSP servers (ElixirLS, lexical, next-ls) is viewed as wasteful, though some report good experiences with newer options and with Zed.
  • IEx is widely praised as a “killer feature” for REPL-driven development and live introspection, including attaching to running nodes.

LiveView vs “just Elixir/Phoenix”

  • Some love LiveView and see it as a major productivity booster versus JS frontends.
  • Others struggle with its mental model, auth patterns, and state handling, and argue it raises the initial learning curve significantly.
  • Several advocate learning Phoenix in classic MVC style first, then OTP, then LiveView.
  • There is concern that Elixir is perceived too narrowly as “the LiveView framework,” overshadowing other backend use cases.
  • Offline/poor-network behavior is a recurring downside; some prefer LiveView-free stacks or pair Phoenix with JS/HTMX.
  • LiveView Native and desktop-oriented approaches (e.g., Livebook/desktop wrappers) are mentioned as promising but under-documented.

Erlang interop & BEAM usage

  • Consensus: you rarely need to write Erlang; you often just call Erlang libs from Elixir or use Elixir wrappers.
  • Understanding some Erlang and OTP docs is helpful but not mandatory for most projects.

Performance, ecosystem, and jobs

  • BEAM’s strengths are cited as concurrency, reliability, and developer productivity rather than raw per-core speed.
  • Some argue other languages (Go/Java/C#) are much faster; replies emphasize that real-world bottlenecks are often parallelism and orchestration, where BEAM shines, plus Nx for heavy number-crunching.
  • Strong praise for Phoenix, Oban, Broadway, Membrane, Nerves, CQRS tooling, and the overall ecosystem “coherence.”
  • Library ecosystem size is a concern: many note abandoned libs and the need to maintain or fork clients (e.g., for external APIs), contrasted with richer JS/Python ecosystems.
  • Job market views are mixed: some see higher-than-average salaries (often senior-focused); others see few roles, lower pay vs mainstream stacks, and risk for startups.

New language features

  • Duration and shift semantics get attention; “shift” is preferred over “add” to avoid misleading algebraic expectations, especially around months.
  • get_in/1 for structs is welcomed as a cleaner way to safely traverse nested data than the older get_in/2 with explicit access paths.

Learning Elixir

  • Recommended entry points include a well-regarded book on Elixir/OTP, Livebook-based exploration of official guides, and exercise sites that mimic “Rustlings”-style practice.