DEV Community: Rirash

Why the Best Startup CTOs Are Quietly Choosing Elixir

Rirash — Sat, 20 Jun 2026 08:59:31 +0000

The business case for a technology decision that compounds over time

When you're choosing a technology stack for a startup, you're not just choosing tools for today. You're choosing the cost structure for the next five years. You're choosing the operational complexity your team will carry forever. You're choosing the hiring pool you'll draw from. You're making a bet on where you'll hit walls.

Most startups make this decision reactively: the founder knows Python, so they use Python. The CTO came from Shopify, so they choose Rails. The seed investors funded a lot of Node.js companies, so Node.js it is.

The startups that choose deliberately — that think about the runtime's properties, not just the language's syntax — often end up at Elixir. This article explains why.

The Senior Engineers Are Moving

Here's a data point worth paying attention to: the State of Elixir 2025 community survey shows that Elixir's user base skews toward experienced engineers. More than 60% of Elixir developers have 5+ years of total programming experience. Many came from Ruby, Python, or Java backgrounds, chose to learn Elixir deliberately, and report not wanting to go back.

This is unusual. Most technology communities have a natural distribution — lots of beginners, a taper toward veterans. Elixir's distribution is inverted. The veterans are over-represented.

The explanation: Elixir rewards experience. The engineers who've maintained large Python codebases understand the GIL's cost. The ones who've scaled Rails applications understand the memory overhead. The ones who've operated Java services understand what JVM GC pauses feel like at 3am. Elixir solves the specific problems that experience teaches you to care about.

When you hire experienced engineers into an Elixir stack, you're hiring people who made an informed, deliberate choice. That's a different quality of team member than someone who's using your stack because it's what they know.

The Compounding Productivity Advantage

Startups live and die by iteration speed. The question isn't "what's the fastest language?" — it's "what stack lets my team ship features the fastest over the next three years?"

Elixir's productivity advantage compounds in ways that aren't obvious at the beginning:

Year 1: You're learning the language and framework. Productivity is similar to other stacks, maybe slightly lower during the learning curve.

Year 2: The patterns are internalized. Phoenix generators handle boilerplate. Ecto makes database work clean. Testing is fast because pure functions are easy to test. The team ships quickly.

Year 3: You're at a scale where other stacks would be adding Redis, breaking into microservices, hiring DevOps specialists to manage growing infrastructure complexity. Your Phoenix monolith is still handling it. Your team is still writing features instead of infrastructure.

Remote.com went from startup to unicorn on a Phoenix monolith. They attribute part of their ability to iterate quickly to not having microservices complexity. When your entire application is one codebase with clean context boundaries, you can refactor across the whole thing without versioning APIs between services.

The Infrastructure Cost Math

Let's run real numbers on a growth scenario.

Scenario: You're serving 10,000 concurrent users at peak. You need 99.9% uptime. You run background jobs for notifications and reports.

Node.js stack:

Web tier: 4 × t3.xlarge (4 vCPU, 16GB) = $560/month
Redis: ElastiCache r6g.xlarge = $190/month
Bull workers: 2 × t3.large (2 vCPU, 8GB) = $120/month
RDS PostgreSQL: db.t3.large = $145/month
Total: ~$1,015/month

Phoenix stack:

Web tier: 2 × t3.xlarge (4 vCPU, 16GB) — Phoenix uses fewer instances = $280/month
RDS PostgreSQL: db.t3.large (also serves Oban) = $145/month
Total: ~$425/month

That's $590/month saved — $7,080/year — on a relatively modest scale. At 100,000 concurrent users, the multiple is similar, but the absolute numbers are larger.

The Phoenix stack also eliminates Redis entirely (using built-in PubSub and Oban for jobs), which removes an operational dependency, a potential failure point, and specialized Redis expertise from your team's skill requirements.

The Hiring Question (Addressed Honestly)

"There are fewer Elixir developers, so hiring is harder."

This is true. There are more Python and JavaScript developers than Elixir developers. If you post a Python role, you'll get more applicants.

But here's the counterargument:

The Elixir candidates who apply are self-selected. An engineer who learned Elixir did it deliberately — it's not taught in most bootcamps, not the default language in most companies. They invested time to learn it because they found it compelling. That's a signal about the quality of candidate.

Senior engineers move to Elixir. The community skews experienced. You're more likely to hire engineers with 7+ years of experience than with 2.

Productivity per engineer is higher. If your PHP team needs 5 engineers to maintain infrastructure that a Phoenix team handles with 3, you're not actually ahead on hiring volume.

The team you hire stays longer. Developers working in Elixir report high job satisfaction. The language is elegant, the tooling is excellent, and the runtime is genuinely interesting to work with. Attrition is lower in communities where developers chose the technology.

Companies that have made the Elixir hiring bet — Remote, DockYard, Erlang Solutions, dozens of startups — report that while the applicant pool is smaller, the signal-to-noise ratio is higher.

The Scaling Cliff Problem

Every technology stack has a scaling cliff — the point at which the architecture requires a fundamental change to handle more load.

Rails hits it around 10,000 concurrent users on typical hardware. The solution: more servers (expensive), or microservices (complex).

Node.js hits it when CPU-heavy work enters the system. The solution: worker threads (code complexity) or separate services (operational complexity).

Java hits it when thread count becomes the bottleneck. The solution: virtual threads (requires Java 21+) or reactive programming (significant code complexity).

Elixir's scaling cliff is much higher. The BEAM was designed to handle millions of concurrent connections per node. Discord ran 5 million concurrent users before the architecture needed significant changes. WhatsApp handled 2 million connections per server.

For most startups, they will never hit Elixir's scaling cliff before reaching a scale where they can afford dedicated infrastructure engineering. You're not deferring the problem — you're genuinely eliminating it for the foreseeable future.

The "Are We Sure We Should Add This Feature?" Problem

Every startup faces this: a feature request that seems simple in a meeting but turns out to require significant infrastructure.

"Let's add real-time notifications." In Node.js: Socket.io, Redis pub/sub, sticky sessions, connection state management. In Elixir: Phoenix PubSub (already there), LiveView (already there).

"Let's add a background job that processes uploads." In Node.js: Bull, Redis, worker threads, retry logic. In Elixir: Oban (PostgreSQL-backed, retry logic included).

"Let's add a live activity dashboard for admins." In Node.js: WebSocket server, React frontend with state management, polling or push logic. In Elixir: Phoenix LiveView, one module.

When features that previously required infrastructure work require only application code, your iteration speed changes. The conversation becomes "let's build it" instead of "let's plan the infrastructure we'd need first."

The Business Continuity Argument

Startups fail for many reasons. A common one that rarely makes the post-mortem: the system fell over when it got popular.

The HN hug of death. The Product Hunt spike. The day you go viral and your servers can't handle the load. The engineering team spends days fire-fighting while potential customers bounce off a 503.

The BEAM was built to not fall over. It was built for Ericsson's telephone switches, where the expectation was nine nines of uptime (99.9999999%). The patterns that achieved that — process isolation, supervisor trees, preemptive scheduling, per-process GC — are in every Elixir application by default.

When you go viral, a Phoenix application scales horizontally (add more nodes with libcluster and they self-configure into a cluster) and stays stable. The individual request error rate might go up slightly. The system doesn't fall over.

That's a different failure mode than the alternatives, and it's the failure mode that matters when you're trying to convert a spike of attention into customers.

The Pragmatic Path In

You don't have to bet the whole company on Elixir on day one. A practical path:

Phase 1: New service in Elixir
Pick a new service or feature — a real-time component, an API, a background processing system — and build it in Elixir. Keep your existing backend. Evaluate the experience over 3 months.

Phase 2: Informed decision
After 3 months, you have actual data: what it's like to develop in Elixir, how it performs, how difficult the hiring was, what the operational experience is.

Phase 3: Expand or maintain
If the experience is positive, expand the Elixir footprint. If it wasn't the right fit, you've learned that cheaply.

Several companies have found that the Elixir service was so much more productive to develop and cheaper to operate that the evaluation expanded organically into the primary stack.

What the Best Startup CTOs Actually Care About

They don't care about which language is theoretically best. They care about:

Shipping velocity: How fast can we build features?
Reliability: Does it stay up? Does it self-heal?
Team productivity: How much of the team's time is features vs. infrastructure?
Cost efficiency: What does this cost to run at scale?
Talent: Can we hire and retain good engineers?

Elixir's answer to each:

Velocity: High, especially as the team gains experience
Reliability: Exceptional — built into the runtime via OTP
Productivity: High feature-to-infrastructure ratio
Cost: 2-5x more efficient than comparable Node.js or Java stacks
Talent: Smaller pool, higher quality, higher retention

These are good answers to the questions that matter.

The Freshcode article "Should Your Startup Use Elixir? Business Case Analysis for 2025" provides additional financial modeling for the Elixir adoption decision. Remote.com's case study (elixir-lang.org, January 2025) is the most detailed account of an Elixir startup's growth trajectory.

Hello, Elixir! A Beginner's Guide to Setting Up and Writing Your First Program

Rirash — Fri, 19 Jun 2026 05:56:43 +0000

Everything you need to go from zero to your first running Elixir code — explained one step at a time

You've heard about Elixir. Maybe someone mentioned it in a podcast. Maybe you read that WhatsApp uses Erlang (Elixir's older cousin) to serve billions of messages. Maybe you're just curious about a language that promises fault-tolerance and concurrency without making your head hurt.

Whatever brought you here — welcome. This article will get you from "I've never written a line of Elixir" to "I have code running on my machine" in about 20 minutes. No previous Elixir knowledge needed. If you've written code in any language before, you'll be fine.

Step 1: Installing Elixir

The cleanest way to install Elixir is through a version manager. This lets you install multiple versions and switch between them easily. The two popular choices in 2026 are asdf and mise.

Using mise (recommended — it's fast and simple)

# Install mise
curl https://mise.run | sh

# Restart your terminal, then install Elixir + Erlang
mise install erlang@27
mise install elixir@1.20

# Tell mise to use these versions
mise use --global erlang@27
mise use --global elixir@1.20

Using asdf (also great)

# Install asdf first from asdf-vm.com, then:
asdf plugin add erlang
asdf plugin add elixir

asdf install erlang 27.0
asdf install elixir 1.20.0

asdf global erlang 27.0
asdf global elixir 1.20.0

Checking the Installation

Open a new terminal and type:

elixir --version

You should see something like:

Erlang/OTP 27 [erts-15.0] [...]
Elixir 1.20.0 (compiled with Erlang/OTP 27)

If you see that — great! Elixir is installed. If you see an error, try closing and reopening your terminal, then running the version check again.

Why do we need Erlang too?
Elixir runs on top of the Erlang virtual machine (called the BEAM). Think of Erlang as the engine and Elixir as the comfortable car body built on top of it. You need both, but you'll mostly interact with Elixir.

Step 2: Meet IEx — Elixir's Interactive Shell

Before we write any files, let's play around in the interactive shell. Type this in your terminal:

iex

You'll see a prompt like:

Erlang/OTP 27 [...]

Interactive Elixir (1.20.0) - press Ctrl+C twice to exit
iex(1)>

The iex(1)> is Elixir asking you to type something. Let's try a few things:

iex(1)> 1 + 1
2

iex(2)> "Hello, World!"
"Hello, World!"

iex(3)> String.upcase("elixir is fun")
"ELIXIR IS FUN"

iex(4)> 100 / 3
33.333333333333336

iex(5)> div(100, 3)    # integer division
33

iex(6)> rem(100, 3)    # remainder
1

You can type any Elixir expression and see the result immediately. This is called a REPL (Read-Eval-Print Loop) — it Reads what you type, Evaluates it, Prints the result, and Loops back for more.

To exit IEx, press Ctrl+C twice, or type :q and hit Enter.

Step 3: Your First Elixir File

IEx is great for experimenting, but real programs live in files. Let's create one.

Create a file called hello.exs (the .exs extension means "Elixir script"):

# hello.exs

IO.puts("Hello, World!")
IO.puts("My name is Elixir.")
IO.puts("I am #{1 + 1 + 1} years old... just kidding.")

Run it:

elixir hello.exs

Output:

Hello, World!
My name is Elixir.
I am 3 years old... just kidding.

A few things to notice:

IO.puts prints a line to the screen (the IO part means "Input/Output", the puts part means "put string")
# starts a comment — Elixir ignores everything after it on that line
#{...} inside a string is string interpolation — it evaluates whatever is inside the braces and puts the result in the string

Step 4: Variables

Variables in Elixir are declared by just using them — no var, let, or const:

# variables.exs

name = "Alice"
age  = 28
city = "Nairobi"

IO.puts("#{name} is #{age} years old and lives in #{city}.")

Alice is 28 years old and lives in Nairobi.

One important thing: Elixir variables are lowercase (or snake_case with underscores). Uppercase names mean something else in Elixir (we'll get to that later).

first_name = "Alice"   # good
firstName  = "Alice"   # works, but not idiomatic Elixir
FIRST_NAME = "Alice"   # this means something different — don't do this yet

Step 5: Your First Module and Function

Scripts with IO.puts are fine for learning, but real Elixir code lives in modules. Think of a module as a container that groups related functions together.

Create a file called greeter.exs:

# greeter.exs

defmodule Greeter do
  # This defines a function called `hello` that takes one argument: `name`
  def hello(name) do
    "Hello, #{name}! Welcome to Elixir."
  end

  # A function with a default argument
  def greet(name, language \\ "English") do
    case language do
      "English" -> "Hello, #{name}!"
      "Spanish" -> "¡Hola, #{name}!"
      "French"  -> "Bonjour, #{name}!"
      _other    -> "Hi, #{name}! (I don't know #{language} yet)"
    end
  end
end

# Now let's use the module
IO.puts(Greeter.hello("World"))
IO.puts(Greeter.greet("Alice"))
IO.puts(Greeter.greet("Carlos", "Spanish"))
IO.puts(Greeter.greet("Marie", "French"))
IO.puts(Greeter.greet("Zeynep", "Turkish"))

Run it:

elixir greeter.exs

Hello, World! Welcome to Elixir.
Hello, Alice!
¡Hola, Carlos!
Bonjour, Marie!
Hi, Zeynep! (I don't know Turkish yet)

Let's break down what we wrote:

defmodule Greeter do ... end — creates a module called Greeter
def hello(name) do ... end — defines a function called hello that takes one argument
\\\ "English" — a default value for an argument (if you don't pass language, it's "English")
case language do ... end — a switch/match statement (we'll learn more about this soon)
_other — a catch-all pattern. The underscore means "I don't care what value this is"
Greeter.hello("World") — calling a function from a module uses ModuleName.function_name(args)

Step 6: Mix — Elixir's Build Tool

For real projects (not just scripts), you use Mix — Elixir's built-in build tool. It creates projects, manages dependencies, runs tests, and more.

Let's create your first Mix project:

mix new my_first_app

You'll see:

* creating README.md
* creating .formatter.exs
* creating .gitignore
* creating mix.exs
* creating lib
* creating lib/my_first_app.ex
* creating test
* creating test/test_helper.exs
* creating test/my_first_app_test.exs

Your Mix project was created successfully.
You can use "mix compile" to compile it, "mix test" to run tests.

Navigate into the project:

cd my_first_app

Look at the structure:

my_first_app/
  lib/
    my_first_app.ex    ← your main code goes here
  test/
    my_first_app_test.exs  ← tests go here
  mix.exs               ← project configuration

Open lib/my_first_app.ex — it already has something in it:

defmodule MyFirstApp do
  @moduledoc """
  Documentation for `MyFirstApp`.
  """

  @doc """
  Hello world.
  """
  def hello do
    :hello
  end
end

Run your project interactively:

iex -S mix

This starts IEx with your project loaded. Now you can call your functions:

iex(1)> MyFirstApp.hello()
:hello

:hello is an atom — a special Elixir value that's basically a named constant. We'll learn about atoms in the next article.

A Quick Reference Card

Here's what you learned today, all in one place:

# Running Elixir
# elixir script.exs         — run a script
# iex                        — interactive shell
# iex -S mix                 — interactive shell with project loaded

# Basic output
IO.puts("text")             # prints with newline
IO.inspect(some_value)      # prints any value (useful for debugging)

# Variables
name = "Alice"
age  = 28

# String interpolation
"Hello, #{name}! You are #{age} years old."

# Basic math
1 + 2        # 3
10 - 3       # 7
4 * 5        # 20
10 / 3       # 3.3333...  (float division)
div(10, 3)   # 3          (integer division)
rem(10, 3)   # 1          (remainder)

# Modules and functions
defmodule MyModule do
  def my_function(arg) do
    # function body
    arg
  end
end

MyModule.my_function("hello")

What's Next?

You've installed Elixir, played in IEx, written your first script, created your first module, and set up your first Mix project. That's a real foundation.

In the next article, we'll dive into Elixir's data types — strings, numbers, atoms, lists, tuples, and maps — and start to see how Elixir thinks about data differently from most languages.

For now, experiment! Try modifying the Greeter module to add more languages. Try writing your own function that does some math. Break things — the error messages in Elixir are actually quite helpful.

The best way to learn Elixir is to write Elixir.

Official Resources: The official Elixir Getting Started guide at hexdocs.pm/elixir is the best companion to this article. IEx's built-in help (h IO.puts, h String) documents every standard library function.

The BEAM VM: The Most Underrated Runtime in Modern Software Engineering

Rirash — Fri, 19 Jun 2026 05:54:54 +0000

Why millions of developers are sleeping on a 35-year-old virtual machine that still solves problems newer runtimes can't

The year is 2026. You're building a real-time system. Notifications, live dashboards, collaborative editing, streaming data — the works. You reach for Go, or maybe Rust, or perhaps you spin up a Node.js cluster and duct-tape it together with Redis Pub/Sub. You deploy, you scale, and three months later you're paging at 3am because your event loop is blocked and 50,000 users just got dropped.

Here's what the Erlang community would tell you, politely, if you asked: we solved this in 1986.

That might sound like hubris. It isn't. The BEAM — the virtual machine that runs both Erlang and Elixir — is arguably the most battle-tested runtime for concurrent, distributed, fault-tolerant systems that exists today. It powers WhatsApp at 2 million connections per server. It runs Ericsson's telecom infrastructure, where nine-nines uptime (99.9999999%) is a contractual obligation, not a marketing claim.

And yet most developers have never seriously considered it. This article is an attempt to fix that.

What Makes a Runtime "Good"?

Before we can appreciate the BEAM, we need a frame for evaluation. A runtime for a modern backend system needs to answer four questions well:

How does it handle concurrency? Not just "does it have threads" — how does it model concurrent work?
What happens when something crashes? Does one failure cascade, or is it contained?
How does it use multiple CPU cores? Is parallelism first-class or bolted on?
What are the latency characteristics? Does garbage collection pause everything?

The BEAM answers all four in ways that are, even today, architecturally distinctive.

Processes: The Fundamental Unit

The BEAM's most important architectural decision is how it models concurrent work. Where the JVM gives you threads and the Node.js runtime gives you an event loop, the BEAM gives you processes.

These are not OS processes. They're not OS threads either. BEAM processes are a language-level abstraction — green threads managed entirely by the runtime. And they are extraordinarily lightweight:

Startup cost: ~2 KB of memory per process
Spawn time: microseconds
Max count: millions on a single machine

Compare this to OS threads, which typically require 1–2 MB of stack space and take milliseconds to spawn. The practical consequence is that you can model your entire domain as concurrent actors without thinking about pooling, thread limits, or resource contention.

A modern Phoenix application might spawn a process per WebSocket connection, a process per background job, a process per cache entry, and still have headroom to spare. This isn't a clever optimization — it's the intended design.

# Spawning a process is this simple
pid = spawn(fn ->
  receive do
    {:hello, sender} -> send(sender, :world)
  end
end)

send(pid, {:hello, self()})

receive do
  :world -> IO.puts("Got a response!")
end

The receive block isn't blocking an OS thread. It's suspending a BEAM process, freeing the scheduler to run something else.

The Scheduler: Fair by Design

The BEAM runs one scheduler thread per CPU core. Each scheduler maintains a run queue of BEAM processes and executes them in round-robin fashion, allocating a fixed number of reductions per turn — roughly 2,000 function calls.

This is preemptive multitasking at the language level. No single process can starve others. A tight loop, a slow database call, a CPU-intensive computation — none of them block the scheduler. When a process exhausts its reductions, it's suspended and the next process runs.

This is fundamentally different from cooperative multitasking systems like Node.js, where a single while(true) loop can freeze the entire event loop. In the BEAM, that loop gets suspended after a few thousand iterations, and everything else keeps running.

The result is predictably low latency, even under load. Tail latencies — the p99, p999 — don't spike the way they do on GC-pausing runtimes.

Memory: Per-Process Garbage Collection

The BEAM gives each process its own private heap. There is no global shared heap. This has two important consequences:

First, GC pauses are local. When a process's garbage collector runs, it pauses that process — and only that process. The rest of the system keeps running. This eliminates the stop-the-world pauses that haunt JVM and Go applications under memory pressure.

Second, process termination is instant memory reclamation. When a process dies — cleanly or by crash — its entire heap is freed in O(1). No GC cycle needed.

┌─────────────────────────────────────────────┐
│                 BEAM Scheduler               │
│  ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐   │
│  │ P1   │  │ P2   │  │ P3   │  │ P4   │   │
│  │ heap │  │ heap │  │ heap │  │ heap │   │
│  │ GC   │  │ GC   │  │ GC   │  │ GC   │   │
│  └──────┘  └──────┘  └──────┘  └──────┘   │
└─────────────────────────────────────────────┘
         No shared state. No shared GC.

Fault Tolerance: "Let It Crash"

This is where the BEAM's philosophy diverges most sharply from other ecosystems. The mantra is "let it crash" — and it's not recklessness, it's architecture.

In most systems, you write defensive code everywhere. You catch exceptions at every level. You validate inputs redundantly. You add try-catch blocks to prevent errors from propagating. And despite all this effort, bugs still crash your process, and when they do, they corrupt state and bring down the server.

The BEAM asks: what if crashing was safe?

Because processes are isolated — no shared memory — a crashing process can't corrupt another process's state. And because the BEAM has a built-in mechanism called supervisors, dead processes get automatically restarted by the runtime.

defmodule MyApp.Application do
  use Application

  def start(_type, _args) do
    children = [
      MyApp.Database,
      MyApp.Cache,
      MyApp.WebServer
    ]

    Supervisor.start_link(children, strategy: :one_for_one)
  end
end

The :one_for_one strategy means: if any child process crashes, restart only that child. The other children keep running. The system self-heals.

This is Erlang's gift to the world — a model for fault-tolerant systems by design, not by exception handling.

Why Now?

The BEAM was designed in the 1980s for Ericsson's telephone switches — systems that couldn't be taken down for maintenance, that handled thousands of concurrent connections, that needed to stay running even when code was buggy.

That description perfectly maps to the systems we're building today.

Real-time collaborative apps, streaming pipelines, AI agent orchestration, IoT device management — these are all domains where the BEAM's process model, scheduler, and fault-tolerance architecture give you a structural advantage.

WhatsApp reached 900 million users with 50 engineers. Discord serves millions of concurrent voice channels on a relatively small infrastructure. Ericsson runs telecom infrastructure at nine-nines uptime. These are not accidents of cleverness — they're the natural outcome of building on a runtime designed for exactly this class of problem.

Getting Started

The best entry point into the BEAM ecosystem in 2026 is Elixir — a modern language built on the BEAM that adds a Ruby-inspired syntax, a macro system, and a world-class tooling ecosystem while inheriting everything the runtime offers.

# Install via asdf or mise
asdf install elixir 1.20.0
mix new my_app
cd my_app
iex -S mix  # Interactive shell with your app loaded

From there, read the official Getting Started guide, then dive into the "Programming Elixir" book by Dave Thomas or "The Little Elixir & OTP Guidebook" by Benjamin Tan Wei Hao. The OTP framework — the set of design patterns and behaviours built on top of the BEAM — is where the real power lives.

Conclusion

The BEAM VM is not a curiosity. It's not a niche tool for telecom engineers. It's a production-proven runtime that has been solving the hardest concurrency and reliability problems in software engineering for nearly four decades.

The systems we're building today — real-time, distributed, always-on — are the systems the BEAM was designed for. The irony is that we built them in ecosystems that required us to rediscover, at great cost, the solutions the BEAM had all along.

The good news: it's not too late to switch lanes.

Want to go deeper? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌The BEAM Book by Erik Stenman is the definitive technical reference for BEAM internals. The Elixir Forum is one of the friendliest technical communities on the internet. And the official Elixir blog publishes regular deep-dives on the language and ecosystem.

WhatsApp Has 2 Million Connections Per Server. What's Your Number?

Rirash — Wed, 17 Jun 2026 14:38:36 +0000

The engineering case studies that prove what the BEAM can actually do

When engineers debate programming languages, the conversation often stays abstract. Performance benchmarks. Theoretical comparisons. "In principle, the actor model should scale better than..."

Let's stop being abstract. There are companies running the BEAM at a scale most engineers will never encounter, with documented results. The numbers are not theoretical. The engineers who built these systems have written about them. Let's look at the evidence.

WhatsApp: 2 Million Connections Per Server, 50 Engineers

In 2014, Facebook acquired WhatsApp for $19 billion. At the time, WhatsApp served 900 million users — with a team of 50 engineers.

The technical foundation: Erlang. Not for political reasons or engineering tribalism. Because at the time of their founding in 2009, Erlang was the only practical option for what they were building.

The numbers that engineers cite most:

2 million simultaneous connections per server — a benchmark their engineers explicitly reported
50 billion messages per day at peak
50 engineers building and maintaining this infrastructure

The 50-engineer number is the most striking. At scale comparable to mid-sized social networks, companies typically have thousands of engineers. WhatsApp did it with 50.

Their CTO Jan Koum chose Erlang for one reason: "Erlang is the right tool for the job." When you need millions of concurrent connections per node with predictable latency and automatic fault recovery, the BEAM is simply the right foundation.

The engineering blog posts from the WhatsApp team describe the specific properties that made Erlang the right choice:

Each connection is a BEAM process (~2KB)
Process isolation means one bad connection can't affect others
The preemptive scheduler keeps latency predictable even at extreme load
Supervisors restart connections automatically when they fail

This is not a language that works at scale despite being weird. It's a language that was built for exactly this scale.

Discord: 5 Million Concurrent Users on Elixir

Discord launched in 2015 and chose Elixir from the start. Their CTO Jason Citron explained the decision: they were building a real-time communication platform, and the BEAM's process model was the natural fit.

By 2020, Discord was serving 5 million concurrent users on their Elixir platform. Their engineering team published a post documenting the experience: "Real-Time Communication at Scale with Elixir at Discord."

Key quotes from Discord engineers:

"What we do in Discord would not be possible without Elixir."
"We wouldn't be able to build it with five engineers if it was a C++ codebase."

The second quote is the remarkable one. Discord's infrastructure team was small — and they attributed that to the BEAM's built-in reliability. When the runtime handles process supervision and crash recovery, your infrastructure team doesn't need to build those systems.

Later, Discord did add Rust for specific latency-sensitive components (their member list sorting and presence system). But they kept Elixir for the core real-time messaging infrastructure. This is significant: when Discord needed maximum performance, they reached for Rust, not Go or C++. They kept Elixir for the system that handles millions of concurrent connections.

Bleacher Report: Infrastructure Costs Cut 8x

Bleacher Report runs sports content for millions of concurrent users. Before Elixir, they ran Ruby infrastructure. After the migration:

Server count reduced dramatically
Infrastructure costs fell significantly
Response times improved substantially

Their engineering team wrote about the migration. The key insight: the Ruby infrastructure required many servers at peak traffic. The Elixir replacement handled the same traffic with far fewer servers. Each Elixir server handled what previously required multiple Ruby servers.

The specific mechanism: a Phoenix server handles concurrent connections in lightweight BEAM processes. A Ruby Puma server uses OS threads or processes. At the same traffic level, Elixir uses a fraction of the memory and CPU.

Klarna: Financial Infrastructure at Bank Scale

Klarna, the Swedish fintech company, uses Erlang for their payment processing infrastructure. They process billions of dollars in transactions through systems built on the BEAM.

Financial infrastructure has requirements that make the BEAM uniquely appropriate:

Zero tolerance for data corruption: BEAM processes share no memory, so a bug in one transaction can't corrupt another's state
Predictable latency: Payment confirmation needs to happen in milliseconds consistently, not just on average
Never-down requirements: Payments infrastructure can't be offline for scheduled maintenance — the BEAM's hot code upgrade capability addresses this

Klarna uses Erlang's hot code loading to deploy updates without downtime. Their infrastructure literally upgrades itself while running, without dropping connections or requiring a restart.

Riot Games: 7.5 Million Concurrent LoL Players

Riot Games runs League of Legends' chat infrastructure on Erlang. At peak, this handles 7.5 million concurrent players.

The choice was explicit: they evaluated multiple options and chose Erlang because no other option could handle the specific combination of requirements:

Millions of persistent WebSocket connections
Low-latency message delivery
Automatic recovery from node failures
Efficient memory usage at scale

Their engineering team documented that Erlang was the only technology they evaluated that met all four requirements simultaneously.

Remote.com: Unicorn Scale Monolith

Remote.com, the global HR platform, built their entire product on Elixir. They grew from startup to unicorn ($3B+ valuation) without ever decomposing their application into microservices.

In January 2025, José Valim featured Remote as an official Elixir case study. Remote's engineering team made the case that:

The Elixir monolith was simpler to develop and deploy than microservices would have been
Phoenix's performance was more than adequate for their traffic levels
OTP's supervision model gave them reliability properties that would have required significant infrastructure work in other stacks

Remote is particularly significant because it's not a "we needed millions of connections" story. It's a "we built a serious business software product and Elixir was simply the right choice" story.

BBC: Serving Hundreds of Millions with a Small Team

The BBC serves web and app traffic to hundreds of millions of users globally. They've adopted Elixir for significant parts of their infrastructure, explicitly for the small-team-large-scale properties.

Their engineering teams report that Phoenix applications handle traffic spikes gracefully — without the horizontal scaling drama that Node.js or Ruby applications require under sudden load.

What These Case Studies Have in Common

Pattern one: small teams, massive scale. WhatsApp's 50 engineers. Discord's small infrastructure team. This isn't coincidence. The BEAM's built-in reliability reduces the engineering work required to keep systems running.

Pattern two: long-lived connections at extreme concurrency. WhatsApp's 2M connections per server. Discord's 5M concurrent users. Riot's 7.5M League chat connections. The BEAM's process model — each connection is a process, each process uses 2KB — makes this scale achievable.

Pattern three: reliability without complexity. Financial systems (Klarna) that can't go down and can't corrupt data. Media systems (BBC) that can handle traffic spikes. Business applications (Remote) that iterate quickly without infrastructure drama.

Pattern four: the engineers chose it deliberately. These aren't companies that backed into Erlang/Elixir by accident. They evaluated alternatives and made an explicit, documented choice. The engineers who built these systems continue to advocate for the technology.

The Skeptic's Objection

"These are outliers. You don't need to handle 2 million connections per server."

Fair. But consider the counterargument: if you're designing a system that might grow, don't you want to choose a foundation that scales well rather than one that will require architectural rewrites under load?

Every scaling crisis looks avoidable in hindsight. The teams who avoided the crisis chose foundations that handled growth gracefully. The BEAM is one of those foundations.

The other objection: "These companies had expert Erlang/Elixir engineers."

True. But the point is that those expert engineers consistently choose the BEAM when the requirements include concurrent connections, reliability, and small team sizes. That's informative signal.

Your System's Requirements

Let me ask you to think about your own system:

How many concurrent connections do you handle at peak?
What happens when one part of your system crashes — does it affect other parts?
How much of your engineering team's time goes to infrastructure reliability rather than features?
What would happen if you could handle 10x your current load on the same hardware?

If any of these questions make you uncomfortable, the case studies above are worth reading carefully. These aren't academic exercises — they're engineering decisions made by teams with real problems, documented honestly.

Where to Go From Here

Read the original source material:

Discord's "Real-Time Communication at Scale with Elixir at Discord" (elixir-lang.org blog, 2020)
Remote's case study (elixir-lang.org blog, January 2025)
WhatsApp's Erlang engineering blog posts (search "WhatsApp Erlang")
Riot Games' "Riot's Engineering Postmortem: League of Legends 2013" (discusses the move to Erlang)

These aren't blog posts making claims. They're engineers describing systems they built, the problems they faced, and the solutions that worked.

The BEAM's reputation is earned. These companies didn't choose it for fun. They chose it because it was the right tool for genuinely hard problems — and it delivered.

The Monterail blog post "Eight Famous Companies Using Elixir — And Why They Made the Switch" collects additional case studies in one place. The official Elixir production stories at elixir-lang.org are worth bookmarking — they're primary sources from engineering teams.

You’re Doing It Wrong The Wake-Up Call That Changed Everything

Rirash — Wed, 09 Apr 2025 07:17:37 +0000

The Stuck Developer

My friend—let’s call him Hamza—was trapped.

Not in a dramatic, cinematic way, but in the slow, soul-crushing grind of job applications, unanswered emails, and projects that vanished into the void. Every day, he sat in the same dimly lit café, headphones on, fingers flying over his keyboard, eyes hollow. His laptop hummed with life; he did not.

I slid into the seat across from him, asking the same question I had for months: “Any responses?”

A slow shake of his head. His gaze stayed locked on the screen, as if staring harder might summon an opportunity.

Then—intervention.

A man at the next table—mid-30s, beard, hoodie that read “Backend Never Dies”—turned toward us and said:

“You’re doing it wrong.”

Hamza and I froze. The stranger didn’t apologize. He stood, grabbed his coffee, and joined our table like he’d been invited.

“Not trying to be rude,” he said. “But I’ve been where you are. And I see this every day.”

His name was Alex.as he introduced, No last name, no LinkedIn plug—just Alex. A former telco engineer turned backend developer who’d helped a dozen juniors land jobs. Not by teaching them to code better, but by showing them what nobody else would.

Hamza leaned in. So did I.
The Hard Truths

Alex asked what Hamza had built.

“A blog API, a to-do app, some microservices…”

A knowing smile.

“Let me guess—FastAPI, PostgreSQL, maybe Docker, but nothing actually deployed? No README, no architecture diagrams, no proof of how you think?”

Silence.

Alex leaned back, locking eyes with Hamza.

“Here’s your first truth: You’re not being ignored because you’re bad. You’re being ignored because you’re invisible.”

“You’re solving problems no one sees. Building things that don’t break. No logs, no tests, no real-world mess. That’s not backend engineering—that’s just coding.”

Then, the gut punch:

“Have you ever debugged someone else’s broken code?”

Hamza admitted he hadn’t.

“Second truth: If you can’t navigate chaos, you’re not ready. Most juniors think the job is building. It’s not. It’s fixing.”

Alex pulled out his phone, opened GitHub, and showed a repo—messy, imperfect, but alive. Daily commits. Failure logs. Diagrams. Notes on what went wrong.

“Hard truth number three: Nobody cares what you can do in theory. They care what you’ve done when everything exploded.”

Hamza swallowed. “Then… what do I change?”

Alex didn’t hesitate.

“Build ugly. Build broken. Deploy something that crashes—then show how you fixed it. Write logs. Document failures. Make your GitHub a war story, not a tutorial graveyard.”

“Don’t apply to 100 jobs. Apply to 20—but make sure your work screams, ‘I solve real problems.’”

Then, the final blow:

“Stop calling yourself a ‘junior.’ Say you’re a backend developer. Act like one. Nobody hires people who look unsure. They hire people who ship.”

With that, he stood, leaving one last piece of wisdom hanging in the air:

“You don’t need permission. You need proof. Stack rejections like XP. At 50, you’ll be unstoppable.”

And just like that—he was gone.

The Turnaround

That night, Hamsa deleted every half-finished project. He picked one idea—a Quran recitation tracker—and rebuilt it, differently.

- Schema first. He mapped the database on paper before writing a single line.

- Tests, logs, edge cases. He hunted for bugs instead of avoiding them.

- Public deployment. He put it on Railway, documenting every failure.

Six weeks later, a DM:

“Saw your repo. We’ve got a junior backend role. You game?”

He started two months ago.

Now? When he sees stuck developers, he tells them what Alex told us.

The Takeaway

This isn’t about luck or genius. It’s about shifting your mindset:

From “Please hire me” to “Here’s what I can do.”
From “I need more tutorials” to “I need a messy project to fix.”
From “I’m invisible” to “I’ll make you see me.”

Being ignored isn’t rejection—it’s feedback. “You’re not visible yet.”

You already know enough to build something real. The question is:

Will it be another perfect, forgettable project—or something ugly, broken, and impossible to ignore?

The Backend Growth Roadmap (Do This Now)

Pick one real-world problem (e.g., Quran tracker, budget app, reminder system).
Design your database first (think relationships, constraints, scale).
Build → Break → Fix (embrace the mess).
Add logs, tests, error handling (simulate production chaos).
Deploy publicly (Railway, Render, Fly.io).
Document everything (README, failure logs, architecture diagrams).
Share with proof (Post it. Tag devs. Ask for brutal feedback.)

Stop waiting for permission. Start building proof.

Inspired? Tag a developer who needs this. Or better yet—open your IDE and build like it’s the project that gets you hired.

Why You’re Not Making Money or Tangible Progress

Rirash — Tue, 11 Mar 2025 06:42:10 +0000

The Painful Reality of Hard Work Without Results

Imagine working or studying for more than 10 hours every day, yet feeling like you’re stuck in the same place. No real progress, no financial breakthrough—just endless effort with nothing to show for it.

I know that feeling because I was once there. For five years, I worked tirelessly, believing I was a professional, yet I had no clients, no major achievements, and no financial growth. It was frustrating. I started questioning everything: Was I not skilled enough? Was I missing something?

But then, I discovered the real reasons behind my stagnation, and everything changed. Today, I want to share with you why this happens, what causes it, and most importantly, how you can break free and start making real progress.

The Trap of "Feeling Busy" Without Moving Forward

Many people believe that working long hours is the key to success. You might think, If I just keep pushing, things will eventually fall into place. But here’s the hard truth: being busy doesn’t mean being productive.

For years, I woke up early, stayed up late, and filled my days with endless work. I convinced myself that I was making progress. But one day, I looked back and realized that despite all my effort, I had nothing to show for it.

I was caught in a cycle of:
✔️ Learning more instead of applying what I knew.
✔️ Working without a clear direction or strategy.
✔️ Avoiding the uncomfortable tasks that actually move the needle.

The solution? Stop focusing on doing more and start focusing on doing the right things. Ask yourself:

Am I just learning and working, or am I applying and executing?

Am I focusing on what truly brings results, or just staying busy?

If you feel stuck, it’s time to shift your mindset from "hard work" to "impactful work."

The Skill vs. Business Gap: Why Being "Good" Isn't Enough

Have you ever seen someone with less skill than you making more money? It’s frustrating, right? But the truth is, being good at something is not enough.

For years, I thought my skills would naturally attract clients and opportunities. But then I saw people who weren’t as talented as me landing high-paying projects. That’s when I realized: success isn’t just about skill—it’s about visibility and positioning.

If people don’t know you exist, they won’t hire you. If you don’t market yourself, no one will see your value. That’s why you need to:

Build a personal brand. Show your work, share your knowledge, and let people know what you do.

Network and connect. Opportunities come from people, not just skills.

Solve real problems. People don’t pay for talent; they pay for solutions.

If you’re not making progress, don’t just focus on getting better—focus on getting seen and selling your value.

The Fear That’s Secretly Holding You Back

Many times, the biggest thing stopping us isn’t a lack of skills or opportunities—it’s fear.

I spent years avoiding the things that could actually change my situation. I didn’t share my work because I was afraid of judgment. I didn’t reach out to clients because I feared rejection. I told myself, I just need more time to improve, when in reality, I was just scared to take action.

Fear keeps us in our comfort zones, convincing us to delay the very things that could lead to progress. But here’s the truth: success is on the other side of discomfort.

If you feel stuck, ask yourself:

What am I avoiding that could change my situation?

What’s one uncomfortable step I can take today?

Growth happens when you stop waiting and start doing—even when it’s scary.

Final Words: Take Control of Your Progress

If you’ve been stuck, it’s time to make a change. Stop believing that just working hard is enough. Instead:
✅ Work on what truly matters, not just what keeps you busy.
✅ Focus on visibility and marketing, not just skill.
✅ Stop letting fear hold you back—take bold action.