How to find Erlang developers in 2026: A sourcing guide

Erlang was designed at Ericsson in 1986 to solve a specific problem: telephone switches that could never go down. Nearly four decades later, it runs critical infrastructure across the internet. WhatsApp handled 40 billion messages per day with roughly 50 engineers writing Erlang. Cisco routes 90% of global internet traffic through nodes controlled by Erlang. Ericsson's 3G, 4G, and 5G base stations, representing 40% of global mobile network market share, run on the BEAM virtual machine that Erlang created.

Erlang's open source ecosystem is smaller than Elixir's but contains critical infrastructure projects on GitHub. RabbitMQ, EMQX, CouchDB, ejabberd, VerneMQ. These are not side projects. They are the messaging, IoT, and database infrastructure that thousands of companies depend on in production. That makes GitHub one of the best sourcing channels for Erlang talent. We covered Erlang briefly in our niche language sourcing guide alongside Elixir. This is the full treatment.

This guide covers where Erlang developers work on GitHub, what separates an engineer who understands OTP from one who learned the syntax, why the Erlang-Elixir relationship matters for your sourcing strategy, and how to build a workflow that finds Erlang engineers who are not looking for jobs.

The Erlang developer market in 2026

Erlang occupies an odd spot in the programming language market. The Stack Overflow 2024 Developer Survey measured its usage at 0.9%, a number that has been roughly flat for years. TheirStack identified 1,876 companies using Erlang. The broader BEAM community, which includes Erlang, Elixir, and Gleam, is estimated at 150,000 to 250,000 developers globally. Pure Erlang practitioners are a subset of that, likely 50,000 to 80,000 people. By any measure, this is a tiny pool.

But the compensation tells a different story. Erlang was the number one highest-paid programming language in the Stack Overflow 2024 survey, with a global median salary of $100,636. In the US, the range runs from $80,000 to $158,000, with senior engineers at companies like Goldman Sachs reaching $293,800. These are not inflated by a few outliers. Erlang engineers work on infrastructure where downtime means dropped phone calls, failed financial transactions, or messaging outages affecting billions of users. The systems do not tolerate mistakes, and the companies running them pay accordingly.

The companies that hire Erlang engineers cluster in a few industries. Telecom is the original home: Ericsson, T-Mobile, and Motorola Solutions all run Erlang in production. Financial services is the second major cluster, with Klarna processing payments on Erlang and Goldman Sachs using it for microsecond-latency trading systems. Then there is messaging and real-time communication, where WhatsApp is the obvious example and ejabberd (the XMPP server) powers messaging at many others. Online gambling is a less obvious but large employer: bet365 serves 20 million-plus users on Erlang for real-time betting, where milliseconds of latency have direct revenue impact. AdRoll handles 500,000 bid requests per second on Erlang for programmatic advertising. Nintendo uses Erlang for the Switch's messaging infrastructure.

Hiring cycles for Erlang developers are long. Expect 60 to 120 days for a senior role, longer if you need someone with specific domain expertise in telecom or financial systems. The bottleneck is not the interview process. It is finding people at all. Most experienced Erlang engineers are employed, well-compensated, and working on problems they find interesting. They are not browsing job boards. The ones who might move care more about the technical problem than the salary, because they are already near the top of the pay range for any language.

One pattern that distinguishes Erlang from most niche languages: the average experience level skews high. Erlang does not attract many new graduates. Most Erlang engineers came to the language after years in other ecosystems, drawn by a specific problem, concurrency, fault tolerance, distributed systems, that other languages handled poorly. A 2-year Erlang developer often has 10 or more years of total engineering experience. The talent pool is small, expensive, and senior. Plan for that.

Where Erlang developers contribute on GitHub

Erlang's open source presence is concentrated in a few high-impact projects. There are not many Erlang repositories on GitHub compared to Go or Rust, but the ones that exist tend to be large, production-hardened infrastructure. GitHub-based sourcing works well for Erlang because the people contributing to these projects are building systems that handle millions of connections.

The runtime itself. erlang/otp (12,100 stars) is Erlang's core repository, containing the language, compiler, standard library, and the OTP framework. Contributors here are working on the foundation that every Erlang and Elixir application depends on. This is a small, selective group. Even meaningful issue discussion or code review on this repo signals a developer who understands the BEAM at a level most engineers never reach. Changes to the scheduler, garbage collector, or distribution protocol require deep systems programming knowledge.

Message brokers. rabbitmq/rabbitmq-server (13,600 stars) is one of the most widely deployed message brokers in the world. RabbitMQ handles message queuing for companies across every industry, and its core is written in Erlang. Contributors know distributed messaging, queue management, clustering, and what it takes to operate infrastructure that sits in the critical path of production systems. emqx/emqx (16,100 stars) is the highest-starred Erlang project on GitHub, an MQTT broker for IoT that handles millions of concurrent device connections. EMQX contributors deal with both Erlang's concurrency model and IoT protocol design.

Databases. apache/couchdb (6,900 stars) is a distributed document database built on Erlang, designed for eventual consistency and multi-master replication. CouchDB's architecture maps directly to Erlang's strengths: fault-tolerant, distributed, built to handle network partitions. Contributors know distributed data systems, conflict resolution, and the tradeoffs of building databases that work across unreliable networks.

Messaging servers. processone/ejabberd (6,600 stars) is an XMPP messaging server that has been in production for over two decades. It powers real-time messaging at large scale and was one of the projects that proved Erlang could work outside Ericsson. vernemq/vernemq (3,600 stars) is another MQTT broker, built for high-availability IoT messaging. Both attract contributors who know protocol implementation, connection management at scale, and what it takes to keep a messaging system running 24/7.

Build tools and ecosystem infrastructure. erlang/rebar3 is the standard build tool for Erlang projects. erlware/relx handles release packaging. hex.pm (shared with Elixir) is the package registry. Build tooling contributors understand the Erlang compilation model, release management, and the operational side of deploying Erlang applications. This is a less obvious sourcing channel, but people who maintain build tools tend to be experienced engineers invested in the ecosystem's developer experience.

Telecom and network protocol libraries. Erlang's roots in telecom mean there are specialized libraries for SIP, DIAMETER, RADIUS, and other telecom protocols. These projects are less visible (lower star counts, smaller contributor bases) but the engineers working on them often have the deepest Erlang expertise. They work in environments where nine nines of availability and real-time response under load are not aspirational but contractually required.

Quality signals in Erlang code

Evaluating Erlang code requires understanding how the language differs from mainstream options. Erlang is a functional language with concurrency built on lightweight processes and message passing. If you are used to reading Java, Python, or even Elixir, Erlang's syntax looks unusual. The quality signals are clear once you know what to look for, though. General seniority signals on GitHub apply, but Erlang has its own markers of real expertise.

OTP design patterns. OTP is Erlang's most important feature and the primary quality signal. An experienced Erlang developer structures applications around gen_server, gen_statem, supervisor, and application behaviours. The signal is not whether they use gen_server but whether they use it correctly. A developer who wraps stateless logic in a gen_server "just in case" is showing inexperience. A developer who designs supervision trees with restart strategies matched to actual failure modes, who knows when one_for_one is appropriate versus rest_for_one, who structures the application tree so a crash in one subsystem does not cascade: that developer understands Erlang at a production level.

Supervision tree architecture. This deserves its own section because it is the strongest quality signal. A well-designed supervision tree shows how the developer thinks about failure. Where are the isolation boundaries? Which processes can crash independently? What is the restart strategy and why? An experienced Erlang engineer's supervision tree reads like a diagram of how the system fails and recovers. Flat supervision trees with everything under one supervisor are a red flag. Deep, carefully partitioned trees with different restart strategies at different levels are the mark of someone who has operated Erlang in production.

Message passing patterns. Erlang processes communicate by sending messages. How a developer handles message passing reveals their understanding of the runtime. Experienced engineers are careful about mailbox management because a process that accumulates messages it never reads will consume memory until it crashes. They use selective receive carefully, understand the performance implications of scanning large mailboxes, and design their message protocols to be explicit about expected message shapes. A developer who writes receive blocks without a timeout or a catch-all clause may not understand how mailbox growth can degrade system performance.

Hot code loading. Erlang supports upgrading running code without stopping the system. This is one of the features that made it viable for telecom, where downtime is measured in seconds per year. Developers who implement proper code_change/3 callbacks in their gen_servers, who understand module versioning and the two-version limit, who can design state migrations that happen while the system is serving traffic: these engineers understand Erlang's operational model at its deepest level. Most developers never use hot code loading. Those who do are working on systems where they cannot afford scheduled downtime.

Distributed Erlang. Erlang has built-in support for clustering nodes and sending messages between processes on different machines. Engineers who work with distributed Erlang understand node discovery, network partition handling, global process registration, and the tradeoffs of net_kernel versus custom distribution protocols. This matters for RabbitMQ clustering, CouchDB replication, and telecom infrastructure spanning multiple data centers. Code that handles nodedown messages correctly and implements split-brain resolution is a strong positive signal.

Error handling philosophy. Erlang's "let it crash" philosophy is not about being careless. It is a deliberate design choice. Instead of writing defensive code that tries to anticipate every failure, you design process hierarchies where failures are expected, isolated, and recovered by supervisors. A developer who wraps everything in try/catch is bringing habits from Java or Python. A developer who uses the {ok, Value} | {error, Reason} tuple convention at API boundaries and lets unexpected errors crash the process (where a supervisor will restart it) understands Erlang's operational model. Whether a codebase uses "let it crash" appropriately is one of the clearest ways to tell production Erlang experience from textbook knowledge.

Testing and property-based testing. Erlang has EUnit for unit testing and Common Test for integration and system testing. But the stronger quality signal is property-based testing with PropEr or QuickCheck. Erlang was one of the first languages where property-based testing caught on, partly because Quviq (the company behind commercial QuickCheck) was founded by Erlang community members. Engineers who write property-based tests for their gen_servers and test their state machines with generated input sequences are working at a level of rigor that is rare in any language.

Dialyzer type specifications. Erlang is dynamically typed, but Dialyzer provides static analysis through type specs and typespecs annotations. Developers who write thorough -spec annotations and use Dialyzer as part of their development workflow care about code correctness beyond what tests alone can verify. Incomplete or missing type specs in a large codebase suggest a developer who has not invested in long-term maintainability.

The BEAM runtime and why Erlang still matters

The BEAM virtual machine was built at Ericsson to run telephone switches. The requirements were extreme: the system could never go down, it had to handle hundreds of thousands of concurrent connections, and it needed to be upgraded while running. Ericsson's AXD301 switch, written in Erlang, achieved nine nines of availability. That is 31 milliseconds of downtime per year. The BEAM was not designed for developer ergonomics or rapid prototyping. It was designed for systems that could not fail.

Three decades later, those design decisions map well to what modern infrastructure needs. WhatsApp scaled to 2 billion users on Erlang because the BEAM handles millions of concurrent connections on a single node. Each connection is a lightweight process, typically using only a few kilobytes of memory, scheduled preemptively by the BEAM's own scheduler. There is no thread pool to tune, no async/await to get wrong. The runtime was built for this from day one.

Erlang's process model is the foundation. Every concurrent unit of work is an isolated process with its own heap, its own garbage collector, and no shared mutable state. Processes communicate by copying messages. This eliminates entire categories of bugs: no race conditions from shared memory, no deadlocks from lock hierarchies, no memory corruption from concurrent access. When a process crashes, nothing else is affected. Its supervisor restarts it and the rest of the system continues. This is not a library you opt into. It is how the runtime works.

The scheduler matters here because it directly affects the systems Erlang engineers build. The BEAM runs one scheduler per CPU core, and each scheduler manages thousands of processes using reduction counting, a form of preemptive scheduling that ensures no single process can monopolize a core. A long-running computation does not block other processes. A misbehaving connection does not degrade the rest of the system. This is why Erlang systems maintain consistent latency under load when systems built on event loops or thread pools start to degrade.

Hot code loading, while rarely used outside telecom, says a lot about Erlang's design philosophy. The system was built to be upgraded without stopping. Two versions of a module can coexist, with running processes migrating from the old version to the new one. This drove decisions throughout the BEAM's design: the module system, process isolation, and state management all assume that code will change while the system is running. Even if your company never uses hot code loading, the mindset it produces (designing for change, thinking about state migration, separating concerns so upgrades are safe) carries over to how Erlang engineers approach every problem.

The Erlang community is small and distinctly professional. Code BEAM conferences (America, Europe, and Lite editions) are the primary gathering points. The Erlang Ecosystem Foundation coordinates efforts across Erlang, Elixir, and Gleam. There is no equivalent of JavaScript's massive, fragmented community. Erlang's is more like a professional guild: small, experienced, focused on production engineering. This has sourcing implications. Conference speaker lists, foundation members, and mailing list participants represent a real fraction of the entire active community. One good referral from inside the community can yield three or four strong candidates.

Erlang versus Elixir: overlapping but distinct

Erlang and Elixir both run on the BEAM. They share OTP, the process model, and the same runtime characteristics. But they are different languages with different communities, and that distinction matters for sourcing. We wrote a separate guide to finding Elixir developers because the two pools overlap but differ in concentration, typical experience profile, and industry footprint.

The relationship is asymmetric. Competent Elixir developers must know some Erlang because Elixir compiles to BEAM bytecode and regularly calls Erlang libraries. The Elixir standard library is a thin layer over Erlang/OTP in many places. When Elixir developers debug performance issues, they often drop into Erlang tooling: observer, dbg, recon. But the reverse is not true. Many experienced Erlang developers have never written Elixir and have no need to. They work in codebases that predate Elixir's existence (2012) by decades.

Where does pure Erlang still win over Elixir? Four situations keep coming up. First, legacy telecom systems. Ericsson, T-Mobile, and Motorola Solutions have Erlang codebases that are 15 to 25 years old. These systems are not being rewritten in Elixir. They need engineers who can read and extend Erlang, understand the specific OTP patterns these systems use, and work within codebases that were written before Elixir's conventions existed. Second, deep OTP and VM internals work. If you are contributing to erlang/otp, modifying the BEAM scheduler, or writing custom distribution protocols, you are working in Erlang. These problems exist below the layer where Elixir adds its abstractions. Third, regulatory-constrained environments. Telecom and financial systems often have regulatory requirements around software changes. Erlang's stability as a language (it changes slowly and deliberately) is an advantage when a language upgrade could trigger a re-certification process. Fourth, infrastructure projects like RabbitMQ, CouchDB, and EMQX. These are Erlang projects and will remain Erlang projects. Contributing to them requires Erlang fluency.

For sourcing, you need to decide which pool you are actually fishing in. If you are hiring for a Phoenix web application, an Elixir developer is what you want. If you are hiring for RabbitMQ internals, Ericsson infrastructure, or Goldman Sachs trading systems, you need an Erlang developer. If you are building new BEAM-based infrastructure and have flexibility, either pool works, but the culture and conventions will differ. Erlang developers tend to write more explicit, lower-level code. Elixir developers tend to use more abstractions and metaprogramming. Neither is better; they reflect different priorities.

The best crossover candidates have contributions to both ecosystems on GitHub. A developer with commits in erlang/otp and phoenixframework/phoenix understands the full stack from VM internals to web application layer. These developers are rare and worth prioritizing when you find them.

How to search for Erlang developers on GitHub

Erlang's small community means GitHub search results are concentrated. Unlike JavaScript or Python where the volume is overwhelming, an Erlang search returns a manageable set of results where most profiles are real practitioners. The niche language sourcing strategies we covered previously apply here, with adjustments for Erlang's ecosystem.

Language filter. Filtering by language:erlang in GitHub's repository or code search surfaces developers with active Erlang repositories. Because the community is so small, the signal-to-noise ratio is high. Someone with multiple Erlang repositories that are not forks is almost certainly a real practitioner. The problem is the opposite of mainstream languages: too few results, not too many.

Target repository contributors. The best sourcing method for Erlang is going directly to the contributor lists of major projects: erlang/otp, rabbitmq/rabbitmq-server, emqx/emqx, apache/couchdb, processone/ejabberd. These projects have hundreds of contributors total, not thousands. You can review every meaningful contributor in an afternoon. Focus on people who have made code contributions (not just documentation or typo fixes) in the last 12 months.

Hex.pm and rebar3 package authors. Erlang shares hex.pm as a package registry with Elixir. Erlang-specific packages are identifiable by their build system (rebar3) and language tag. Package authors who maintain widely-used Erlang libraries are building what the rest of the ecosystem depends on. Cross-referencing hex.pm with GitHub profiles is manual but works well for a community this small.

Conference speakers and foundation members. Code BEAM conference speaker lists are publicly available. The Erlang Ecosystem Foundation publishes its working group members. The community is small enough that a single conference might cover a real percentage of active practitioners. These lists are high-density sourcing channels. A Code BEAM speaker with an active GitHub profile is worth investigating.

Contribution recency calibration. The Erlang community moves slower than fast-growing ecosystems. A developer who made significant contributions 12 months ago is still relevant when the core language changes at a measured pace. Widen your recency filter beyond what you would use for Go or Rust. An Erlang engineer who contributed to RabbitMQ 18 months ago did not forget how to write Erlang. They may have moved to a proprietary codebase that is not visible on GitHub.

Adjacent language signals. Look for developers whose primary GitHub language is Elixir but who have Erlang repositories or contributions to Erlang projects. Also check for C developers who contribute to the BEAM runtime (it has C internals), and Haskell or Prolog developers with Erlang side projects, since the functional and logic programming backgrounds transfer well. Erlang's community also draws from Python and Java backends when engineers hit concurrency problems those languages cannot solve cleanly.

A practical Erlang sourcing workflow

Here is what works, from discovery to first outreach.

Step 1: Define what kind of Erlang engineer you need. "Erlang developer" covers a wide range. Are you hiring for telecom infrastructure (SIP stacks, DIAMETER, base station software)? Messaging systems (XMPP, MQTT, message brokers)? Financial services (low-latency trading, payment processing)? IoT device management? General distributed systems? Each domain maps to different projects, different companies, and different candidate profiles. An engineer who spent ten years at Ericsson writing telecom software has a different skill set than one working on RabbitMQ plugins, even though both write Erlang.

Step 2: Map the target repositories and companies. Based on the domain, build two lists. The repository list: which open source projects would your ideal candidate contribute to? For messaging infrastructure, that is RabbitMQ, ejabberd, VerneMQ, EMQX. For IoT, EMQX and VerneMQ. For databases, CouchDB and Riak (now Riak KV). For the language ecosystem itself, erlang/otp and rebar3. The company list: which companies employ Erlang engineers in your target domain? Ericsson and T-Mobile for telecom. Klarna and Goldman Sachs for finance. bet365 for real-time systems. WhatsApp (Meta) for messaging. Engineers leaving these companies are the highest-probability candidates.

Step 3: Extract and evaluate contributors. Go through the contributor lists of your target repositories. Filter for meaningful contributions: code changes, code reviews, design discussions. You will likely end up with 30 to 80 names, not hundreds. That is normal for Erlang. Review each profile for the quality signals described above: supervision tree design, OTP patterns, message passing architecture, distributed Erlang experience. Cross-project contributions and code review participation are strong seniority indicators, especially when the same names keep appearing across multiple important projects.

Step 4: Cross-reference the Elixir community. Some of your strongest candidates will come from the Elixir side of the BEAM ecosystem. Look for Elixir developers who also contribute to Erlang projects, who have written Erlang libraries, or who discuss Erlang/OTP internals on ElixirForum or in conference talks. These crossover developers understand the full BEAM stack, can work in Erlang codebases, and bring modern development practices from the Elixir side. The Elixir sourcing guide covers where to find them.

Step 5: Tap community channels directly. The Erlang community is small enough that direct engagement works. The Erlang Ecosystem Foundation's Slack, the erlang-questions mailing list, and Code BEAM conference networks are places where a respectful, specific job posting will be seen by a real percentage of the active community. "We're hiring an Erlang engineer to work on our MQTT broker's clustering implementation" will get attention in a way that "Senior Backend Developer needed" will not. Be specific about the technical problem. Erlang engineers are motivated by interesting infrastructure challenges.

Step 6: Write outreach that demonstrates understanding. Erlang developers get fewer recruiter messages than React or Python developers, but the ones they do get are usually generic and wrong. Good developer outreach references specific contributions: "I saw your work on RabbitMQ's quorum queue implementation, specifically how you handled the Raft consensus recovery path. We're building a distributed message broker for financial data and your approach to partition handling is directly relevant to what we need." The community is small enough that poorly researched outreach will get noticed and talked about. Specificity is not optional.

Step 7: Scale with tooling. The manual workflow above is thorough but slow, and the small community means you will exhaust your target repos quickly. Tools like riem.ai automate the discovery and evaluation steps by analyzing 30 million-plus GitHub events per month and surfacing Erlang developers based on actual contribution patterns. Instead of manually reviewing contributor lists across six repositories, you describe the technical profile in natural language ("Erlang developers who contribute to messaging infrastructure or distributed systems, with OTP and supervision tree experience") and get a ranked list with contribution summaries and quality scores. For a pool this small, any time saved in sourcing matters.

Frequently asked questions

How many Erlang developers are there?

The broader BEAM community (Erlang, Elixir, and Gleam combined) is estimated at 150,000 to 250,000 developers globally. Pure Erlang practitioners are a subset of that, likely 50,000 to 80,000. The Stack Overflow 2024 Developer Survey puts Erlang usage at 0.9%. That is a small pool, but the engineers in it tend to be senior, deeply experienced, and working on infrastructure that handles enormous scale. WhatsApp ran 2 billion users with roughly 50 Erlang engineers. The ratio of infrastructure impact to team size is unlike almost any other language.

What salary should I expect to pay Erlang developers?

Erlang was the highest-paid programming language in the 2024 Stack Overflow Developer Survey, with a global median of $100,636. In the US, salaries range from $80,000 to $158,000, with senior engineers at companies like Goldman Sachs reaching $293,800. The pay reflects scarcity: Erlang engineers typically work on mission-critical systems in telecom, finance, and messaging infrastructure. Companies competing for this talent include WhatsApp, Ericsson, Cisco, Klarna, and bet365.

What is the difference between Erlang and Elixir developers?

Both run on the BEAM virtual machine and use OTP, but they are distinct communities with different strengths. Competent Elixir developers must understand some Erlang (they call Erlang libraries, debug at the VM level), but the reverse is not true. Pure Erlang is still preferred for legacy telecom systems, deep OTP/VM internals work, regulatory-constrained environments where stability of the language matters, and performance-critical infrastructure where direct BEAM access is needed. Elixir developers tend to focus on web applications (Phoenix), while Erlang developers tend to focus on messaging, telecom, and low-level infrastructure.

Is Erlang still worth hiring for in 2026?

Yes, for specific domains. Erlang is not growing the way Go or Rust are, but the systems running on it are not being rewritten. WhatsApp still runs Erlang. Ericsson still builds telecom infrastructure on it. RabbitMQ, one of the most widely deployed message brokers in the world, is written in Erlang. CouchDB, ejabberd, and EMQX are all Erlang. If you are maintaining or extending any of these systems, or building new infrastructure where the BEAM's concurrency and fault-tolerance model is the right fit, Erlang engineers are the right hire. The language is stable and mature, which is an advantage in regulated industries.

Can I hire Elixir developers for Erlang projects?

Sometimes, but with caveats. Elixir developers who have worked at the OTP level, contributed to Erlang libraries, or debugged BEAM internals can transition to Erlang codebases effectively. Application-level Elixir developers who primarily use Phoenix and have never read Erlang source code will need significant ramp-up time. The syntax difference is real but secondary to the conceptual gap: Erlang's standard library conventions, its approach to error tuples, and its module structure differ meaningfully from Elixir idioms. Look for Elixir developers with Erlang contributions on GitHub as the best crossover candidates.

What Erlang projects should I look for on GitHub?

The most important repositories are: erlang/otp (12,100 stars, the language and runtime itself), rabbitmq/rabbitmq-server (13,600 stars, the widely-deployed message broker), emqx/emqx (16,100 stars, MQTT broker for IoT), apache/couchdb (6,900 stars, distributed document database), processone/ejabberd (6,600 stars, XMPP messaging server), and vernemq/vernemq (3,600 stars, another MQTT broker). Contributors to any of these projects work on serious distributed systems in production. Even issue triage and code review participation on erlang/otp signals deep BEAM expertise.