What If Your Language
Was Already Distributed?

The gravity well

Most apps are born single-node.

Scaling means escaping the gravity well:

• rip the assumptions out of code that assumed one machine
• bolt on a broker, a queue, a coordination service
• re-think state that was never meant to move

Expensive. Risky. Often a rewrite.

Elixir apps are born in orbit

The network, process coordination, supervision, message passing —
already there, whether you use them today or not.

You don't escape the gravity well. You were never in it.

① The desk datacenter

A weekend project: scrape a large pile of documents —
the kind you may have heard about in the news —
and make them searchable.

Two machines, one cable

Storage on one. Compute on the other.
An ad-hoc datacenter on my desk.

How I "distributed" it

# Spread thousands of extraction workers across both machines.
# Horde decides which node each one lands on.
for email <- emails do
  Exstein.Distributed.HordeSupervisor.start_child(
    {Exstein.Distributed.EntityExtractor, email.id}
  )
end
            

I didn't write a networking layer.
I changed where processes run.

② Livebook

The pitch: replace Jupyter in your toolbelt.

What you actually get is more — because of distribution.

A notebook that reaches into a live system

• Connect the notebook to a running node
• Analyse real state and real data, in place
• No export, no CSV dump, no stale snapshot

Your analysis runs where the data already lives.

③ Mob

A framework that runs the BEAM inside iOS and Android apps.

Lots of distribution wins here. Start with a pedestrian one.

One pipeline for two platforms

• iOS and Android apps both talk to the dev server over BEAM distribution
• Not an HTTP bridge, not a websocket shim — the same wire the cluster uses
• A superior dev connection: RPC into the app, read its state, hot-load code

Demo

drive a running phone app from the laptop · introspect live state

"We have Kubernetes."

"We already have orchestration, self-healing, scaling, service discovery."

"So we don't need Elixir."

They look like competitors

Both do supervision · self-healing · distribution · scaling.

The overlap is real — and it's only at the surface.

They work at different granularities.

Different layers, same idea

Pod restart is a sledgehammer: kill the container, lose in-memory state, wait seconds.

Supervisor restart is a scalpel: one failed process restarts, millions keep running.

They fill each other's gaps

Proof they compose: libcluster's Kubernetes strategy —
BEAM nodes discover each other through the K8s API.

I ran them together

last job — placeholder for the concrete story

Kubernetes manages your machines.
Elixir manages what happens inside them.
You want both.

Scale 'later'?

• You start with distribution solved
• Scaling isn't a rewrite — your code was distributed from line one
• The industrial-grade version is already running
• …and it's Elixir, so it's pleasant to build with

The false choice

You've been conditioned to pick one:

easy to build  |  scales industrially

You can have both.