$ cat choices/elixir.md
the call
I reach for Elixir when concurrency and fault-tolerance are the product, not a feature I'll bolt on later. I don't pick it for a CRUD app that'll never see a hard real-time load.
The BEAM was built for the problem most stacks fight: thousands of independent things happening at once, and any one of them failing without taking the rest down. OTP gives you fault isolation, supervision, and back-pressure as the default shape of the system, not a library you reach for after the first outage. When concurrency and resilience are the actual job, that’s the floor, not the ceiling.
Elixir is not a general-purpose hammer. If the workload is request-in, response-out with no real concurrency story, the BEAM’s strengths are dead weight and you’ve taken on a less common language for nothing. The hiring pool is smaller and the ecosystem is thinner than the mainstream worlds. Picking it because it’s elegant when the problem doesn’t actually need it is résumé-driven, and the team pays the tax forever.
A real-time gig marketplace is a concurrency problem. Matching, presence, and live updates happening across thousands of sessions at once. At GigSmart I built the backend on Elixir/BEAM/OTP so fault isolation was the default, not something bolted on after the first incident, serving two React Native apps off that one core. The runtime matched the shape of the problem instead of fighting it.— see: works / GigSmart
Pick the runtime whose default behavior matches the hardest part of your problem. If fault-tolerance is a feature you plan to add later, you’ve already lost. Resilience is an architecture, not a patch. The skill isn’t knowing Elixir; it’s being honest about whether your problem is actually a concurrency problem before you reach for the tool built for one.
the gaps — what it costs even when it’s right
The hiring pool is smaller. You’re recruiting from a narrower bench and onboarding people who’ve never seen OTP. The language is easy to learn; thinking in supervision trees and “let it crash” is not.
The ecosystem is thinner. For anything off the beaten path you’ll write the client the mainstream world already has on a shelf. Usually fine, occasionally a real detour.
Raw number-crunching isn’t its lane. The BEAM is tuned for soft real-time and IO, not heavy CPU math. When the bottleneck is computation, you’re reaching past it. See Go for the heavy-IO carve-out pattern.
used at
works / GigSmart