Scrolls
13 min read
On this page

Why Elixir?

Elixir is a functional language that runs on the BEAM, the same virtual machine that powers Erlang. If you've ever wondered how WhatsApp handled two million connections per server with a tiny engineering team, or how Discord routes millions of concurrent voice chats through a handful of nodes, the answer in both cases is the BEAM. Elixir gives you that same machinery with modern syntax, better tooling, and a community that doesn't shy away from web development.

This isn't a language you pick because it's trendy. You pick it because you have a specific problem: lots of concurrent connections, soft real-time requirements, or a need for a system that keeps running while parts of it are on fire.

The BEAM is the Real Story

The language is mostly a vehicle for the runtime. The BEAM was built at Ericsson in the 1980s for telecom switches that had to maintain "nine nines" of availability — about 31 milliseconds of downtime per year. To get there, the engineers made a few unusual choices:

  • Every unit of work runs in a lightweight process. Not an OS thread, not a coroutine. A BEAM process is roughly 300 bytes of overhead at start, and you can have millions of them.
  • Processes don't share memory. They communicate through messages.
  • The scheduler is preemptive at the function-call level, so one bad process can't starve the rest.
  • Processes can be linked and supervised, so when one dies, the system knows and can react.
  • Code can be hot-swapped on a running node. Telecom switches couldn't be rebooted to deploy a fix; the runtime had to support upgrade-in-place.

This is what people mean when they call Elixir "concurrent by default." It's not a library on top of threads. It's the substrate.

Elixir came along in 2011. José Valim, who created it, wanted Erlang's runtime with modern syntax, polymorphism, metaprogramming, and a sane build tool. He built Elixir on top of the existing BEAM so it interoperates seamlessly with Erlang code — calling Erlang from Elixir is a single function call, no FFI ceremony. This means Elixir inherits 30+ years of battle-tested telecom infrastructure for free.

# spawning a million processes — this completes in a few seconds
1..1_000_000
|> Enum.map(fn i ->
  spawn(fn -> Process.sleep(:infinity) end)
end)
|> length()

Try that with OS threads and your machine will fall over before you hit ten thousand. The BEAM does this comfortably because each process is a userland construct managed by the runtime, not a kernel-level thread.

A common framing is that the BEAM is a small operating system in itself: it schedules its own processes, manages its own memory per-process, handles its own IO, and supports hot code loading. Once you see it that way, a lot of the design choices stop feeling exotic and start feeling like the natural shape of an OS for high-concurrency work.

Immutability Isn't Aesthetic, It's Mechanical

Every value in Elixir is immutable. When you "modify" a map, you get a new map. This sounds wasteful until you realize it's the only way the BEAM's concurrency model works without locks. Two processes can't corrupt each other's state because they can't see each other's state. Garbage collection happens per-process, so a long GC pause in one worker doesn't pause the whole VM.

user = %{name: "Ada", age: 36}
older = %{user | age: 37}

user.age   # 36 — original is untouched
older.age  # 37

The runtime uses persistent data structures and structural sharing under the hood. Updating a 10,000-key map doesn't copy 10,000 keys — it copies the path from the root to the changed node and shares everything else. So immutability isn't as expensive as it looks.

Coming from Python or Ruby, this feels restrictive. After a month, you stop noticing. After six months, mutable state in other languages starts looking like a footgun. The bugs that plagued you in concurrent Java code — race conditions, half-updated objects, ConcurrentModificationException — simply don't exist in Elixir, because there's no shared mutable thing to race over.

"Let It Crash" Is Not a Slogan

In most languages, a defensive function checks every input, wraps every IO call in try/catch, and tries to keep going no matter what. In Elixir, the convention flips. You write the happy path. If something unexpected happens, the process dies. A supervisor restarts it in a known-good state.

This works because processes are isolated. A crash doesn't take down the system, it takes down one task. Joe Armstrong, who designed Erlang, used to point out that this is how physical systems work — a blown fuse doesn't burn down the house, it isolates the failure.

In practice this means your code looks cleaner. You don't have nil-checking ceremonies everywhere. You let pattern matching enforce shape, and trust the supervision tree to handle the rest.

# typical Elixir worker
defmodule Worker do
  use GenServer

  def init(state), do: {:ok, state}

  def handle_call({:process, item}, _from, state) do
    # if this raises, the process dies. supervisor restarts it.
    # we don't catch — we crash deliberately.
    result = do_work(item)
    {:reply, result, state}
  end
end

Compare to the same code in a defensive style — wrapped in try/catch, returning sentinel values, propagating failure flags. The defensive version is longer and bug-prone because every call site has to handle the sentinel correctly. The let-it-crash version delegates failure to a single, dedicated mechanism: the supervision tree.

Soft Real-Time, Not Hard Real-Time

Elixir is great for soft real-time work — stuff where you need consistent low latency but a missed deadline doesn't crash a rocket. Chat, gaming backends, financial dashboards, IoT telemetry. The BEAM scheduler reduction-counts every process and forces context switches, so no single computation can hog a core.

The practical effect is consistency under load. A Node.js or Python service often shows fine median latency and terrible p99 latency — most requests are fast, but a few get stuck behind a slow neighbor or a GC pause. The BEAM's per-process heap and preemptive scheduler flatten this distribution. Discord has written about p99 latencies staying under 10ms while serving millions of concurrent connections. That's the kind of curve the runtime is built for.

It's not for hard real-time (medical pacemakers, avionics) and it's not the right pick for raw single-threaded number crunching. If you're doing matrix multiplication or training neural networks, use the right tool. Though even there, Nx and Bumblebee have been quietly turning Elixir into a serious option for ML inference, and Livebook (Elixir's notebook environment) has become a credible alternative to Jupyter for some workflows.

Who Actually Uses It

Worth grounding this in real production:

  • WhatsApp ran their entire messaging backbone on Erlang/BEAM with around 50 engineers serving 900 million users at the time of the Facebook acquisition.
  • Discord uses Elixir for their real-time messaging fanout. They've written publicly about scaling a single GenServer to handle millions of concurrent users in a guild, and built their own ETS-backed Manifold library for distributed message delivery.
  • Pinterest rewrote their notification system in Elixir and cut server count from 30 to 15 while doubling throughput.
  • Bleacher Report moved from Rails to Elixir and went from 150 servers to 5.
  • Cars.com, PepsiCo, and Heroku all run substantial Elixir workloads.
  • Klarna runs significant payment infrastructure on Erlang and Elixir.
  • Adobe has used Elixir for collaborative document editing.
  • Brex built parts of their financial backend on Elixir.

The pattern: companies hit a concurrency wall in Ruby, Python, or Node, and Elixir was a way out without rewriting everything in Go or Rust. The migrations rarely make headlines because the upside is operational ("we run fewer servers and have less downtime") rather than feature-driven, but the case studies that exist all share that shape.

There's a common pattern in benchmarks where Elixir loses on raw single-request throughput but wins on requests-per-second-at-target-latency. The runtime is optimized for handling many concurrent things consistently, not for being the fastest at any one of them. If you're benchmarking by hammering one endpoint with one client, Go and Rust will look better. If you're benchmarking by simulating thousands of concurrent users while measuring tail latency, the picture flips.

Comparison With Other Languages

Against Go: both handle concurrency well. Go's goroutines are cheap, but they share memory, so you still need mutexes and channels and the discipline to use them correctly. Elixir gives you isolation by default. Go has better single-thread performance and a simpler deployment story (one binary). Pick Go for CLI tools and CPU-bound services. Pick Elixir for stateful, long-lived, message-heavy systems.

Against Node.js: Node is event-loop concurrency on a single thread. One slow handler blocks everything. Elixir is preemptive across all cores. Node wins on ecosystem size and frontend integration. Elixir wins on consistency under load.

Against Rust: different category. Rust is for when you need C-level performance and zero-cost abstractions. Elixir is for when you need uptime and developer velocity. People often pair them — write the hot path in Rust as a NIF, orchestrate it from Elixir.

Against Ruby: this is the most common migration story. Ruby is fast to write, slow to run, and concurrency is painful (GIL, thread-unsafe gems). Elixir feels familiar to Rubyists (José Valim came from Rails core) but scales horizontally without effort. Phoenix is faster than Rails by an order of magnitude on most benchmarks.

Against Java: Java has mature concurrency primitives, the JVM is fast, and the ecosystem is enormous. But the BEAM's process model makes failure handling and stateful work simpler than the JVM's thread-and-lock model. For long-running, distributed, message-heavy systems, Elixir wins on simplicity. For raw throughput on single-machine compute, Java wins.

Against Python: Python has won data science and ML, full stop. For web backends, Python's async story is improving but still imposes the "color" problem (sync vs async functions). Elixir's processes don't have this distinction — every process is concurrent and every function looks the same.

When Elixir Is the Right Choice

  • Real-time features: chat, presence, live dashboards, multiplayer games.
  • IoT and telemetry pipelines, where you have millions of devices reporting state.
  • Phoenix LiveView apps, where you want SPA-like interactivity without writing JavaScript.
  • Background job systems with stateful workers.
  • Anything where uptime matters more than peak single-request throughput.
  • Distributed systems where nodes need to coordinate. The BEAM has built-in clustering — Node.connect/1 and you have a distributed Erlang network with message passing across machines.
  • Pipeline-shaped workloads with backpressure (GenStage, Broadway).

When It's Not

  • CPU-bound numerical work where every nanosecond counts. Use Rust, C++, or Julia.
  • Mobile apps. There's no good story for client-side Elixir.
  • Tiny scripts and CLI utilities. The startup time and tooling overhead make Python or Go a better fit.
  • Teams that need to hire fast in a market with limited Elixir talent. The pool is smaller than Java or Python, full stop.
  • Domains where the ecosystem is thin. Game engines, scientific computing libraries, ML training — all possible but the muscle is elsewhere.

A useful rule of thumb: if the bottleneck of your system is "we can't keep enough connections open" or "one slow handler is dragging down everything else" or "we keep losing state when a worker crashes," Elixir is on the table. If the bottleneck is "we need to multiply gigantic matrices fast," it isn't.

There's also a team-fit question. Elixir rewards engineers who like thinking about systems holistically — supervision strategies, message flow, state ownership. It's less rewarding if your team prefers to write isolated functions and let a framework wire everything up. That doesn't mean Elixir teams don't use frameworks; Phoenix is excellent. But the parts of an Elixir application that determine its quality (the supervision tree, the GenServers, the process boundaries) are not framework concerns. They're application architecture, and you have to design them.

What Elixir Is Not Trying to Be

A few things people sometimes assume about Elixir that aren't accurate. It's not "the next Ruby" — Ruby is alive and well, and José Valim still contributes to both. It's not "the JVM killer" — the JVM has its own strengths and a much larger ecosystem. It's not "Erlang with prettier syntax" — that undersells the metaprogramming, the Mix toolchain, the Protocol polymorphism, and Ecto. And it's not "easy" — the syntax is approachable but the runtime model is unfamiliar enough that the first few weeks feel slow.

What it is, more accurately: a careful repackaging of one of the best concurrent runtimes ever built, with modern syntax, a cohesive standard library, a strong build tool, and a community that takes documentation and testing seriously. That's enough to make it the right tool for a meaningful slice of backend work.

A Brief Word on the Ecosystem

Elixir's ecosystem is small but high-quality. The killer apps:

  • Phoenix — the web framework. Productive, fast, mature.
  • Phoenix LiveView — server-rendered interactive UIs without writing JavaScript. Used by GitHub Codespaces, Cars.com's notification system, and a growing list of companies replacing React with it.
  • Ecto — the database wrapper and query builder. Schema definitions, changesets for validation, composable queries.
  • OTP (built into the runtime) — supervisors, GenServers, and the rest of the actor framework.
  • Nerves — for embedded Linux. People build commercial IoT products on it.
  • Broadway — for data ingestion pipelines (Kafka, RabbitMQ, SQS, etc).
  • Oban — the de facto background job library, backed by Postgres.

You won't find ten competing libraries for any given problem. The community is small enough that one or two solid options emerge for each domain, and most teams converge on the same picks. This makes onboarding faster but means you sometimes have to write your own when you have niche needs.

Common Pitfalls

Treating Elixir like Ruby with different syntax. It's not. If you write imperative loops with mutable accumulators in disguise, you'll fight the language constantly. Lean into recursion, pattern matching, and pipelines.

Ignoring the OTP layer. GenServer, Supervisor, and the rest of OTP are where the value lives. People who write "Elixir without OTP" get a slow Ruby. Learn the actor model early.

Over-engineering with processes. Not every function needs to be a GenServer. Use processes for state, isolation, or concurrency — not for organizing code. Modules organize code.

Underestimating the learning curve. The syntax is approachable but the mental model (immutability, message passing, supervision) takes weeks to internalize. Don't expect to be productive in three days.

Assuming it scales magically. The BEAM gives you the tools, but you can still write a single-process bottleneck. Discord's blog on hitting GenServer message queue limits is required reading.

Picking it for the wrong reason. "It's cool" is not a reason. "Our payment processor times out and our checkout flow needs sub-100ms p99" is a reason. "We run too many Rails servers because of slow socket handling" is a reason. If you can't articulate the constraint that pushed you to Elixir, you'll bounce off it.

Not investing in observability. Telemetry, AppSignal, or PromEx — set up something on day one. The BEAM exposes incredible runtime metrics (process count, message queue lengths, GC stats) that are wasted if you're not pulling them. You'll need them when scaling questions come up.

Key Takeaways

  • Elixir's value comes from the BEAM: lightweight processes, preemptive scheduling, no shared memory, supervision trees.
  • Immutability and message passing aren't ideology, they're what makes lock-free concurrency possible.
  • "Let it crash" is a real engineering strategy backed by supervisors, not a shrug.
  • Production users like Discord, WhatsApp, and Pinterest chose it for concurrent, stateful, real-time workloads.
  • Pick Elixir when uptime and concurrency dominate. Skip it for CPU-bound, single-threaded, or tooling-heavy work.
  • The hardest part isn't the syntax, it's unlearning shared-state habits from other languages.
  • The ecosystem is small but converges on a few high-quality tools per problem domain — easier onboarding, occasionally a thinner library shelf.
  • The migration story is repeated across dozens of companies: hit a concurrency wall in Rails or Node, move stateful workloads to Elixir, run a fraction of the servers with better tail latency.