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

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.