Elixir / Erlang: market

Vacancy

an open job that cleared the quality gate and lists at least two technologies

Observed candidate

a candidate whose stack contains this technology; an aggregate — not a single record leaves the perimeter

Matchable candidate

not counted yet

Window

jobs open at the moment the snapshot was built

Top 5: elixir, postgresql, elasticsearch, aws, ci/cd. Elixir (must — 1.16+) and understanding of Erlang / OTP underneath. Phoenix — the main web framework. Phoenix LiveView — rich interactive UI almost without JavaScript (de-facto frontend standard in the Elixir world 2024–2026). Ecto — DB work (not a classic ORM, but a set of composable tools: schemas, changesets, query DSL). PostgreSQL. OTP abstractions: GenServer (processes with state), Supervisor (supervision trees), GenStage / Flow, Task, Agent. Broadway — concurrent data pipelines (Kafka / RabbitMQ / SQS). Oban — reliable background jobs on PostgreSQL. ExUnit — tests. Dialyzer + typespecs — static type analysis. Telemetry — metrics and observability. Nx / Bumblebee — the growing Elixir ML ecosystem (José Valim investing in this direction). Mix — build and dependencies. Docker + Kubernetes. Knowledge of distributed Erlang (nodes, clustering — libcluster) — Senior must for high-load.

BEAM — the Erlang virtual machine, on which both Erlang and Elixir execute. Its key feature — the actor model: a program consists of many extremely lightweight processes (not OS processes — BEAM's own processes, you can create millions of them) that are fully isolated from each other (don't share memory) and communicate only by passing messages. This gives: concurrency (BEAM efficiently distributes processes across all CPU cores), fault tolerance (a fallen process doesn't take down the others), soft real-time (the scheduler doesn't let one process block the system). OTP (Open Telecom Platform) — a library of time-tested abstractions on top of this: GenServer (process with state and standard behavior), Supervisor (a process whose job is to watch children and restart fallen ones by a given strategy), supervision tree (a tree of supervisors — the structure of the entire application). The «let it crash» philosophy: don't try to handle every conceivable error with defensive code, but allow the problematic process to crash and be restarted into a clean known state by the supervisor. It's precisely the combination of BEAM + OTP that makes Elixir / Erlang a uniquely good choice for systems that must hold many simultaneous connections and not fall.

Phoenix LiveView — a Phoenix framework technology for building rich interactive user interfaces almost without writing JavaScript. How it works: the page is rendered on the server, after loading a persistent WebSocket connection is held between browser and server; on user action (click, input) the server recomputes state, calculates the minimum diff of changed HTML and sends it to the browser, which precisely updates the DOM. Result — SPA-level interactivity (live forms, on-the-fly validation, real-time updates, chats, dashboards), but all logic on the server, in one language, without a separate frontend application and without duplication of business logic between front and back. Why a killer feature: LiveView is especially good precisely on Elixir, because it relies on BEAM's strengths — holding a huge number of simultaneous WebSocket connections with minimal resources (one BEAM process per connection) and reacting instantly. For a backend engineer this means the ability to do a modern real-time UI without going into full SPA frontend development. LiveView — the main reason many choose Phoenix, and the de-facto UI standard in Elixir projects 2024–2026. Limitation — needs stable connection and low latency; for complex offline scenarios classic SPA may still be chosen.

Elixir / BEAM wins: (1) systems with massive simultaneous connections and per-connection state — chats, messengers, presence, notifications, multiplayer, real-time dashboards (the classic example — Discord serves millions of simultaneous users on Elixir). (2) When fault tolerance is critical — supervision trees and «let it crash» give reliability that's hard to replicate. (3) Real-time UI via Phoenix LiveView without a separate frontend. (4) Distributed systems — clustering is built into the platform. Go: easier to hire, better for CPU-bound and cloud-native / DevOps tooling, faster «cold» performance on number crunching, lower entry barrier. Node.js: single language front+back, huge market and ecosystem, good for I/O-bound APIs. The main downside of Elixir — not technical, but staffing: very narrow specialist market (both vacancies and candidates), functional paradigm + OTP require re-learning thinking. Strategy for CIS: Go or Node for market capacity and entry into the profession; Elixir — a conscious choice as a second language for a specific class of tasks (real-time, fault-tolerance) and for international remote with a shortage premium.

Elixir and Erlang — two languages on the same BEAM virtual machine, fully compatible (from Elixir you can call any Erlang library and vice versa). The difference — in syntax and the ecosystem around them. Erlang — the original (since 1986, Ericsson): pragmatic, minimalist, specific Prolog-like syntax; used in telecom, messaging (WhatsApp historically — Erlang), infrastructure (RabbitMQ written in Erlang), in legacy systems. Elixir (since 2012, José Valim) — a modern language on the same BEAM: pleasant Ruby-like syntax, metaprogramming, powerful Mix build tool, rich modern ecosystem (Phoenix, LiveView, Ecto, Nx). What to learn: in 2026 the answer is almost unambiguous — learn Elixir. Practically all new vacancies, new projects, new content, conferences and community — around Elixir; it's Elixir that forms the labor market of the segment. Erlang should be learned «along the way» at the level of understanding — because OTP, supervision, processes, many libraries and the platform's mental model itself — that's Erlang under Elixir. Pure Erlang as a separate career goal makes sense to consider only for a specific niche (telecom, supporting large Erlang systems). Conclusion: write in Elixir — understand Erlang / OTP under the hood.

Yes, 67% of Elixir vacancies — full-remote or hybrid, and for this stack remote is not a bonus, but the main way to work. The reason is simple: local Elixir vacancies in any individual CIS country are few, so the market is international by nature. Remote-friendly Elixir employers: Remote.com (itself on Elixir, all-remote by ideology), Supabase, Duffel, Cars.com, Felt, many SaaS startups. Relocant hubs: Berlin (notable Elixir community, ElixirConf EU), Amsterdam, Lisbon, Serbia, Georgia. English — must: without it the international Elixir market (which is the main market) is inaccessible. For an Elixir engineer English — not a «salary plus», but a condition of access to most vacancies overall.

Assumes backend experience in another language (Elixir is almost never taken as a first). The main difficulty of entry — not syntax, but paradigm shift: functional thinking (immutability, pattern matching, recursion instead of loops, pipe operator) and the process / OTP model. Roadmap: 1) Language — official getting-started guide at elixir-lang.org, book «Programming Elixir» (Dave Thomas), «Elixir in Action» (Saša Jurić — the best book on thinking in OTP). 2) Functional basics — pattern matching, immutability, pipe, work with collections (Enum / Stream). 3) Processes and OTP — spawn, message passing, then GenServer, Supervisor, supervision tree; this is the heart of Elixir, without it knowing the language is useless. 4) Mix — projects, dependencies, tests (ExUnit). 5) Ecto — schemas, changesets, queries to PostgreSQL. 6) Phoenix — routing, contexts, controllers. 7) Phoenix LiveView — mandatory for 2026. 8) End-to-end pet project: Phoenix application with LiveView UI + Ecto + PostgreSQL + GenServer for background logic + Oban + tests + deploy (Elixir releases / Docker). 9) Distribution — nodes, clustering. Resources: Saša Jurić's books, Pragmatic Studio courses (Elixir / LiveView — excellent), Exercism (Elixir track — free), Elixir Forum (very friendly community), Elixir Radar newsletter, ElixirConf talks on YouTube. A backend developer from another language masters productive Elixir in 4-8 months — most time goes to getting used to OTP thinking.

Senior Elixir owns the language, BEAM platform and design of fault-tolerant concurrent systems. Functional thinking: immutability, pattern matching at the reflex level, function composition, proper recursion, conscious use of metaprogramming (macros — and understanding when NOT to apply them). OTP expertise: designing supervision trees and restart strategies, GenServer and its pitfalls (when a process becomes a bottleneck), GenStage / Broadway for back-pressure, proper decision «what should be a process and what — a regular module». BEAM: understanding of scheduler, process mailbox, ETS (in-memory tables), profiling, diagnosing production issues (observer, recon), memory management. Distribution: clustering (libcluster), inter-node communication, and understanding of its limitations (network partitions, consistency). Phoenix / LiveView: contexts, production-level design, LiveView under load. Ecto: changesets, complex queries, migrations, transactions, multi. PostgreSQL: advanced SQL, indexes, query plans. Testing: ExUnit, testing concurrent code, property-based (StreamData). Type safety: typespecs + Dialyzer. Observability: Telemetry, metrics, tracing. DevOps: Elixir releases, Docker, Kubernetes, hot-code-upgrade (rarely, but Senior must understand). Soft: code review, mentoring (Elixir newcomers struggle with OTP), communication with product. English for Senior+ — mandatory: the main Elixir market — international remote, without English it's inaccessible.