Elixir 1.19

Original Article ↗ Hacker News Discussion ↗

Language Evolution & Stability

  • Many praise Elixir’s incremental, non‑breaking evolution (including the new typing work) as a model for “finishing” a language while still improving it.
  • Users report stress‑free upgrades over many years; the desire to upgrade comes from useful features, not compatibility pressure.
  • This is contrasted with painful version jumps in other ecosystems (Python 2→3, Perl 6, Ruby 1.8→1.9/2, PHP, Java 8→11+, Swift, Scala 2→3, .NET, C/C++, Rust async, Node CJS/ESM).

Types & Static Analysis

  • Several are excited by built‑in, progressive type checking and see it as a major milestone.
  • Concerns are raised that Elixir types could devolve into “any everywhere” like TypeScript; others argue:
    • Pattern matching already makes a lot of existing Elixir code structurally “half‑typed”.
    • Types are integrated into the language, not a separate “typed dialect”, so active libraries are likely to adopt them.
  • Dialyzer’s “success typing” is criticized as rarely catching bugs; commenters ask if the new system will be stricter (warn on any possible failure) or more like Dialyzer.

Phoenix, Macros & Framework Churn

  • Some complain about Phoenix/LiveView churn, under‑maintained packages, and moving best practices; LiveView’s long pre‑1.0 phase is cited.
  • Phoenix is perceived by some as macro‑heavy and DSL‑like; maintainers counter that:
    • A small fraction of the public API is macros.
    • Most user code (contexts, controllers, templates) is plain functions.
  • There’s a general debate about macros vs verbose APIs: critics dislike tooling/debugging friction; defenders note all large web frameworks are effectively collections of DSLs, macros or not.

Tooling, Docs & Developer Experience

  • One commenter finds Elixir tooling “decades behind” and documentation noisy, with dense modules (e.g., GenStage) and few gentle introductions.
  • Many others strongly disagree, highlighting:
    • Mix (build/tasks), ExUnit (testing), IEx (REPL), and BEAM observability as standout tools.
    • Hexdocs and inline docs (h in IEx) as a documentation gold standard, often better than other languages they’ve used.
  • Editing/debugging (especially language server/IDE support) is acknowledged as weaker than top‑tier JVM/.NET ecosystems.

Performance & 1.19‑Specific Improvements

  • The new MIX_OS_DEPS_COMPILE_PARTITION_COUNT option shows substantial speedups for native dependency compilation in benchmarks, especially on multi‑core machines.
  • Some confusion arises about timing methodology (cached vs fresh builds), but follow‑up runs from scratch confirm meaningful wins.
  • Inclusion of SBOMs in releases is welcomed by people working in regulated or enterprise environments.

Ecosystem, Use Cases & Alternatives

  • Elixir is clarified as a dynamic, compiled language targeting BEAM; .ex files compile to bytecode, .exs scripts compile/run in memory.
  • Several stress that most Elixir devs rarely need to write Erlang; both share the same semantics and OTP runtime.
  • OTP’s actor model, immutability, preemptive scheduling, and process linking are presented as advantages over Python‑style concurrency, even if Python’s GIL story is evolving.
  • Suggested sweet spots: highly concurrent IO‑bound systems, web apps, brokers, long‑running network services, and embedded/edge (Nerves).
  • Gleam is discussed as a statically typed BEAM language: praised for minimalism but with fewer OTP integrations and tooling; one design choice (1/0 = 0) is called out as dangerous.

Community Reports & Adoption

  • Multiple commenters describe very positive production experience, painless upgrades, and strong reliability compared to Python/Ruby stacks.
  • Some founders say they started companies specifically to use Elixir, citing Livebook, LiveDashboard, and community support as major enablers.
  • A dissenting voice reports macro‑induced complexity, spaghetti dependencies, poor hiring story, and underwhelming docs; others respond point‑by‑point that this doesn’t match their experience.
  • A few wish for more diversity on the client‑side and mobile stories, feeling Phoenix/LiveView doesn’t fit everyone’s mental model and that more experimentation (as in JS/TS land) would be healthy.