What I mean when I say that machine learning in Elixir is production-ready
Enthusiasm for Elixir and the BEAM VM centers on its strengths in highly concurrent, fault-tolerant systems, with proponents arguing it’s well-suited for real-time web services and emerging machine learning tooling (e.g., Nx, distributed Livebook). Critics counter that functional programming concepts, weak static typing, a smaller and sometimes fragile ecosystem, and the difficulty of hiring experienced Elixir/OTP engineers make it a risky choice for many teams compared to Python, TypeScript, Go, or Rust. Several engineers share production experience—both positive and negative—highlighting that Elixir can be extremely productive for small, expert teams, but that its advantages often appear theoretical until an organization commits deeply to the platform.
Fit of BEAM/Elixir and why it hasn’t “taken over”
- Many see Erlang/Elixir as ideal for real-time, concurrent, distributed systems (chat, messaging, streaming), less so for simple request/response SaaS.
- Multiple comments attribute limited adoption to: FP unfamiliarity, lack of static typing, inertia around OO/curly-brace languages, weaker ecosystem, and few visible jobs.
- Some argue its advantages can feel theoretical from the outside; you must “go all-in” (OTP, supervisors, ETS, clustering) before its strengths clearly beat “good enough” stacks with Redis, Kubernetes, etc.
Strengths highlighted
- Excellent concurrency model: lightweight processes, preemptive scheduler, soft real-time behavior, fault-tolerant supervision trees, easy horizontal scaling and clustering.
- Makes full use of all cores by default; good fit for web backends that must stay responsive under load and tolerate failures.
- Integrated tools (OTP, ETS, Mnesia, LiveView, Nx, Livebook) reduce need for external queues, caches, cron, and some devops complexity.
- Some report stable long-term production use with few issues and praise DX, especially with good editors and language servers.
Criticisms and pain points
- Performance: good for parallel throughput and latency under load, but slower for raw single-threaded computation versus Go/Java/Rust; number crunching typically offloaded (or handled via Nx).
- Tooling complaints: some IDE plugins are weak; error messages (especially from Mnesia/Erlang layers) can be opaque.
- Language complexity: multiple exception and string types, macro-heavy style, perceived “combinatorics” and renamings; some found upgrades brittle and libraries buggy or seemingly abandoned. Others dispute this, citing long-term stability.
Typing, reliability, and ML
- Several see lack of strong/static typing as a blocker for large teams; some are moving to typed ecosystems (Python+mypy, Go, .NET) for safety and hiring.
- Others say struct types, Dialyzer, and upcoming gradual typing are sufficient.
- Elixir ML pitch centers on Nx, GPU/cluster execution, and “distributed²” Livebook, but one commenter criticizes the keynote for lacking concrete performance numbers.
Ecosystem, hiring, and alternatives
- Library coverage (e.g., AWS, various APIs) seen as weaker than Python/Java/Go/Rust.
- Hard to hire experienced Elixir/OTP engineers; many Elixir devs are beginners or consultants.
- Gleam is discussed as a typed BEAM alternative, but its concurrency story and documentation are viewed as immature.