MORE THAN OBJECTS
Concurrency-Oriented Programming
A Better Model for a Dynamic World
Object-oriented programming has had its moment starting with static objects and inheritance. Since the world is dynamic, messy, and deeply parallel, your software needs to reflect these qualities as well. Therefore, you need an additional lens: concurrency-oriented programming. Adding a suitable concurrency model and a battle-tested virtual machine helps you overcome today’s challenges facing digital infrastructure critical to society: hacker attacks, hardware failures, software bugs, sky-rocketing cloud costs and resilient augmented software development.
Summary
After reading this article, you will understand the essence of concurrency-oriented programming, suitable programming ecosystems, and, its relevance in an agentic context:
Model the world as it is. Build software from lightweight, isolated processes that mirror real-world concurrent activities – users, calls, connections, background jobs – rather than one single, monolithic sequential program.
Communicate between processes using asynchronous messages; do not share mutable state. This makes distribution, scaling, and failure recovery dramatically simpler.
Design for failure from the beginning. Use supervisors to isolate faults and restart lightweight processes and modules as needed. Let it crash really means letting the system handle crashes responsibly.
Use the right tool. If you need soft real-time performance, high availability, and massive concurrency, Erlang or Elixir on the BEAM (the Erlang virtual machine) provide these properties by design, not by accident.
Improve augmented software engineering. Elixir won Tencents AI model and programming language benchmark, and, OpenAI use Elixir for its open-source orchestration framework Symphony that polls issue trackers to deliver pull requests.
The X Factors
The X factors below show how companies like Motorola, Ericsson, WhatsApp and the BBC use a concurrency-oriented programming approach to achieve:
2X faster development of new services.
10X better availability with downtime under 5 minutes per year.
10X safer systems that are hard to hack or crash.
10X more users and transactions, within milliseconds.
10X less costs and energy.
That is a lot of Xs and each one is backed by data, see Berardi, Cathcart, Cesarini, CVE and Rubio in the For Further Inspiration and Learning section below.
Yesterday: The Job to Be Done
Let us see how the telecom world evolved from the 1980s onwards. Global voice calls, then mobile voice calls, then smartphones and apps. Millions of concurrent users. Hardware that fails. Software with bugs. Ambulances on the other end of the line.
The people who set out to solve this – Joe Armstrong, Mike Williams, Robert Virding and their manager, Bjarne Däcker, at Ericsson – were not trained software engineers or programmers. Armstrong was a rocket scientist, Williams a telecom engineer, Virding a physicist and Däcker an electronics engineer. Freed from software orthodoxy, they reasoned from first principles about what a telecom-grade language would need and how to create one:
Prototyping: having ideas is the starting point; you need to prove they work as well (Williams).
Real-time, secure, scalable: soft real-time is important because human lives indirectly depend on it (Däcker).
Reliable distributed systems in the presence of software errors and, in practice, hardware errors too (Armstrong).
First Principles
Based on the insights above, Armstrong distilled three principles that shaped Erlang, and, arguably, describe the world itself:
The World is Concurrent
Things happen simultaneously. The runtime should transparently handle three related-but-distinct ideas:
- Concurrency: many tasks on one unit, interleaved by a scheduler.
- Parallelism: many tasks across several units, think multi-core, which barely existed when Erlang was designed.
- Distribution: many tasks across several units wherever they happen to live.
The key insight is that the virtual machine should automagically handle all three, allowing the software engineer to focus on solving the business problem.
Things Do Not Share Data – They Communicate with Messages
Shared memory is possible, but it makes distribution and failure recovery dramatically harder. Treat processes as immutable data structures that exchange messages, and the whole model, including principle 3, falls into place.
Things Fail
Anything that can go wrong will go wrong (Murphy was, appropriately, an aerospace engineer). Rather than trying to prevent every failure, design the language to embrace failure: supervision trees isolate failures and recover automatically.
Here is an important caveat to the famous "let it crash" slogan: Let things crash responsibly by having the system handle crashes via supervision trees. A telecom switch should not crash. It is fine if a single call goes down, because you can set it up again semi-automatically.
Today: The Right Tool For the Job
If the job is digital infrastructure critical to society, e.g. telecom, fintech, digital health, media and defence, the tool should natively reflect the three principles above. Enter Erlang and Elixir.
Get Erik Schön’s stories in your inbox
Join Medium for free to get updates from this writer.
Remember Robert Virding’s First Rule of Programming:
Any sufficiently complicated concurrent program in another language contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Erlang.
You can build concurrent systems in Rust or Go and these languages are the right tools for the job when it comes to heavy numerical computations. What Erlang and Elixir offer is a proven virtual machine (the BEAM), refined since the mid-1980s, that supports the three principles above out of the box.
Since 1998, Erlang has brought functional/declarative code, immutable data, message passing, concurrency and error-handling primitives, and an open-source ecosystem that has been called the best European open-source project since Linux.
Elixir inherits the BEAM and its environment, draws on ideas from Ruby and Clojure, brings a front-end focus and consistently ranks among the top two most admired languages, with Phoenix LiveView the most admired web framework according to Stack Overflow’s Developer Surveys 2022–2025.
The list of organisations betting on this technology stack is telling: Adobe, Apple, Amazon Web Services (AWS), BBC, Bloomberg, Broadcom, Cisco, Discord, Ericsson, Facebook, Financial Times, Klarna, Maersk, Mastercard, Motorola, PepsiCo, RabbitMQ, Red Bull Racing, Siemens, Tesla, Toyota, Volvo and WhatsApp.
Tomorrow: Even Better, Faster, More-for-Less
Backed by WhatsApp/Meta, Ericsson, and the Erlang Ecosystem Foundation, the near future looks bright on three fronts:
Even better with gradual typing, i.e. type inference and gradual type-checking for every Elixir program without introducing type annotations.
Even faster through full-stack development in a single team using Phoenix LiveView by eliminating separate frontend codebases.
Even more for less through effective generative and agentic augmentation techniques (AI) on the BEAM where a recent study by Tencent showed that Elixir had the highest completion rate across models when compared among 20 different programming languages. As a concrete example, OpenAI use Elixir for its open-source orchestration framework Symphony that polls issue trackers to deliver pull requests, citing Elixir’s superior concurrency model and resilience.
Takeaway
Concurrency-oriented programming is a way of modelling software that reflects how the world actually behaves – concurrent, message-passing and failure-prone – and is well-suited for digital infrastructure critical to society where resilience, security and scalability are crucial, e.g. fintech, digital health, media, telecom and defence.
The world is dynamic. Your programming model should be, too.
For Further Inspiration and Learning
This article is based on my talk Concurrency-Oriented Programming (video, slide deck) at the DevLin developer conference. That talk is based on presentations, articles, books and theses by Francesco Cesarini, Robert Virding, Joe Armstrong, Mike Williams and Bjarne Däcker – so I am standing on the shoulders of giants. Joe, Mike and Robert developed Erlang independently of the related work by Carl Hewitt (Actor Model) and Tony Hoare (Communicating Sequential Processes, CSP).
You can find my work on leadership, strategy and ways of working, e.g. the books The Art of Change, The Art of Strategy and The Art of Leadership, at Yokoso Press, Medium and YouTube.
Articles, books and videos referenced in or relevant for the article, and, for further inspiration and learning:
- Aleynikov, Serge. Is Go still a ‘modern’ language in 2026?
- Armstrong, Joe. Making Reliable Distributed Systems in the Presence of Software Errors
- Begley, Michael. Ericsson – 150 Years of Innovation
- Berardi, Ettore. How Elixir Powers the BBC: From PoC to Production at Scale
- Bhatti, Shahzad. The Byzantine Generals Problem: A Modern Performance Analysis in Elixir, Erlang, and Rust
- Cathcart, Will. Improving WhatsApp’s Server Efficiency by 25%
- Cesarini, Francesco. Which Companies Are Using Erlang, and Why?
- Cesarini, Francesco & Woff, Eberhard. Evolution of the Erlang Eco System with Francesco Cesarini
- CVE. Common Vulnerabilities and Exposures Database
- Däcker, Bjarne. Concurrent Functional Programming for Telecommunications
- Däcker, Bjarne. CS Lab and All That …
- Hebert, Fred. The Zen of Erlang
- Guttenbergovitz, Krzysztof (Krzyś). Elixir & We’ve Been There Before (Or: The Aqueduct Had Running Water All Along)
- Hoare, Sir Tony, Hewitt, Carl & Armstrong, Joe. Concurrency Panel Discussion with Sir Tony Hoare, Joe Armstrong and Carl Hewitt
- Jurić, Saša. Elixir in Action
- Kay, Alan & Armstrong, Joe. Joe Armstrong Interviews Alan Kay
- Rubio, Manuel. Which Companies Are Using Elixir, and Why?
- Thomas, George. From Babysitting to Managing: Why OpenAI’s Symphony Changes How We Work With Coding Agents
- Valim, José. Elixir v1.20 released: now a gradually typed language
- Valim, José. Why Elixir is the best language for AI
- Virding, Robert. Virding’s First Rule of Programming
