Why Elixir? Common misconceptions

Original Article ↗ Hacker News Discussion ↗

Adoption, mindshare, and industry use

  • Many feel Elixir/BEAM is extremely well-suited to backend and “microservice-like” workloads, yet remains niche compared to Node/Java/Go.
  • Explanations offered: lack of marketing, resume-driven adoption, JS/TS hype cycle, organizational inertia, and language popularity being only weakly correlated with technical quality.
  • Some argue plenty of real systems run on Elixir (national data portals, banks, telecom, large chat platforms), but these deployments don’t get much visibility.
  • Others point out some early showcase companies have moved parts of their stack away, reinforcing perception risk.

Interop, ecosystem, and infra fit

  • Early DB tooling was perceived as Postgres-first and weaker for Oracle/SQLite, though others report Oracle and SQLite support are now workable.
  • Push to use BEAM primitives like ETS instead of Redis is seen by some as technically valid but “adoption-unfriendly” because it doesn’t align with common stacks.
  • Strong disagreement on Kubernetes fit: some say Elixir’s “do it all in one node/cluster” model clashes with ephemeral containers; others say Elixir works fine on k8s and is complementary if you understand both.
  • Concern that BEAM’s strengths (stateful processes, clustering, hot upgrades) are underused when Elixir is treated as “just another microservice.”

LiveView and frontend approaches

  • LiveView is praised for productivity and “no-JS” workflows, especially for internal/CRUD-style apps.
  • Critics argue it quietly turns a stateless web into a stateful, websocket-heavy system that’s fragile under crashes, deploys, or flaky connections, and that these tradeoffs are under-acknowledged.
  • Some prefer React/GraphQL or other frontends with Phoenix (Inertia, Vite, Channels); a few wish Phoenix embraced React more directly for consumer-grade UIs.

Erlang vs Elixir and learning path

  • Broad consensus: you can become highly productive in Elixir without learning Erlang first; Erlang knowledge is “nice to have” for deeper BEAM/OTP understanding, not a prerequisite.
  • Some prefer Erlang’s more “bare-metal” feel; others stress that processes, message passing, and behaviors are first-class in both and that they’re more like dialects than different languages.

Types, reliability, and “let it crash”

  • Lack of static typing is the single biggest hesitancy for many; others report years of productive use without it.
  • Supporters say pattern matching, guards, immutability, small set of core types, specs + Dialyzer, and strong test culture mitigate much of what people want from static types.
  • Opponents, especially in large codebases, say dynamic typing makes refactoring and onboarding harder; they miss compiler guarantees and precise tooling.
  • Ongoing work on gradual/set-theoretic types is noted, but several say it’s still far from TS/Go/Rust-level guarantees.
  • Long thread on “let it crash”:
    • Pro side: supervision trees and process isolation make crashes localized and auto-recoverable; better to optimize for recovery than attempt to preclude all failures.
    • Skeptical side: this doesn’t prevent logic/type bugs from reaching users; static typing and fault tolerance solve different problems and both can be valuable.

Developer experience, tooling, and docs

  • Many praise Elixir’s standard library consistency (especially around the pipe operator), OTP’s breadth, and exceptionally good, “how and why” style documentation.
  • The REPL, introspection into running systems, and BEAM observability are repeatedly called out as major quality-of-life wins.
  • VS Code LSP support (ElixirLS) exists and is actively used, though some still perceive the overall IDE story as weaker than mainstream typed languages.
  • Syntax divides people: control flow feels approachable to some, but pattern-matching/binary syntax and macros can look alien or intimidating.

Performance and where BEAM fits

  • BEAM is viewed as outstanding for IO-bound, highly concurrent, fault-tolerant systems, but not ideal for raw CPU-heavy workloads due to scheduling overhead and immutability costs.
  • Typical recommendation: keep performance hotspots in NIFs/ports or other languages, and orchestrate them from Elixir.
  • Some argue that AI/ML libraries like Nx/EXLA are impressive but lag far behind Python’s ecosystem and model coverage for practical ML/LLM work.

Alternatives: Gleam and others

  • Gleam frequently comes up as “Elixir + static typing”: BEAM-based, interops with Elixir/Erlang, and attractive to teams who like BEAM semantics but require static types.
  • Several commenters say they’d bet heavily on Gleam long term, or that their positive Elixir experience has made them look at Gleam.

Jobs and career calculus

  • Multiple people mention lack of Elixir job openings as a primary deterrent, even if they like the language technically.
  • This creates a chicken-and-egg problem: companies avoid Elixir due to perceived hiring pool risk; developers avoid it due to perceived job scarcity.