DEV Community: Matheus de Camargo Marques

A SEDA Web Server in Erlang: When an Architecture Paper Becomes a Teaching Exercise

Matheus de Camargo Marques — Thu, 05 Nov 2026 12:16:17 +0000

A SEDA Web Server in Erlang: When an Architecture Paper Becomes a Teaching Exercise

Traditional web servers based on synchronous TCP connections hit a wall at scale. Each connection consumes an OS thread, each thread reserves megabytes of stack, and the context-switching overhead grows until the server spends more time managing threads than serving requests. The usual escape hatch — distributing across clusters — adds cost and operational complexity without solving the underlying problem.

The ERLDA paper by Fernando Areias and Adolfo Neto, presented at the I Workshop em Engenharia de Software para Programação Funcional (SE4FP 2025), argues that Erlang’s BEAM virtual machine and the SEDA (Staged Event-Driven Architecture) model are a natural fit for this problem. But more interesting than the argument is the exercise it suggests: implement a minimal HTTP server with three SEDA stages under OTP supervision.

That exercise is a masterclass in architectural thinking. It forces the student to confront the same design decisions that production systems face — queue backpressure, stage isolation, failure recovery — in a codebase small enough to reason about completely. This article walks through that exercise, explains why Erlang maps to SEDA so cleanly, and connects it to the broader arc of learning to build verifiable concurrent systems.

What SEDA actually proposes

SEDA was introduced by Welsh, Culler, and Brewer in 2001 as a response to the limitations of both thread-per-request and pure event-driven servers. Its core idea is simple:

Decompose the application into stages connected by explicit event queues. Each stage performs a subset of request processing and is executed by a pool of threads.

A stage has three components:

An incoming event queue.
A thread pool that drives execution.
An application-supplied event handler that processes events.

The queues are not an implementation detail. They are the control boundary that lets each stage be managed independently. If the processor stage becomes a bottleneck, its queue grows, and the system can shed load, throttle, or scale that stage alone — without touching the acceptor or the writer.

SEDA was designed for Java, but its abstractions are language-agnostic. The question the ERLDA paper asks is: what happens when you implement SEDA in a language where processes are cheap, mailboxes are queues, and supervision is a language primitive?

Why Erlang is the natural substrate for SEDA

The mapping between SEDA and Erlang/OTP is almost embarrassingly direct:

SEDA concept	Erlang equivalent
Stage	A process (or pool of processes)
Event queue	A process mailbox
Thread pool	A `poolboy` pool or a supervisor-managed set of workers
Event handler	A `gen_server` callback
Queue backpressure	Selective receive, bounded mailboxes, or explicit queue processes
Stage isolation	Process isolation (separate heaps, separate failure domains)
Stage recovery	OTP supervisor

This is not a coincidence. Erlang’s actor model is a staged architecture by default: each process has an isolated mailbox, processes communicate by asynchronous message passing, and failures are contained to the process that crashes. SEDA formalizes what Erlang already does natively.

The ERLDA paper makes the memory argument explicit: the BEAM VM is designed to support millions of simultaneous processes with efficient resource usage, prioritizing vertical scalability and operational simplicity over cluster-based horizontal scaling. A SEDA stage implemented as a pool of Erlang processes costs kilobytes per process, not megabytes per thread. The architectural model and the runtime substrate are aligned.

The three-stage exercise

The exercise proposed in the ERLDA discussion — and the one I want to walk through here — is a minimal HTTP server with three stages:

[ Acceptor ] --> [ Request queue ] --> [ Processor pool ] --> [ Response queue ] --> [ Writer ]

Each arrow is a message-passing boundary. Each stage is a separate process or pool. OTP supervision wraps the whole thing so that the failure of any stage does not bring down the system.

Stage 1: The acceptor

The acceptor owns the listening socket. It accepts connections, reads the raw request bytes, and enqueues them for processing. It does not parse, does not validate, does not generate responses. Its only job is to move bytes from the network into the pipeline.

-module(acceptor).
-behaviour(gen_server).

start_link(Port) ->
    gen_server:start_link({local, ?MODULE}, ?MODULE, Port, []).

init(Port) ->
    {ok, ListenSocket} = gen_tcp:listen(Port, [binary, {active, false}, {reuseaddr, true}]),
    self() ! accept,
    {ok, #{socket => ListenSocket}}.

handle_info(accept, #{socket := LS} = State) ->
    case gen_tcp:accept(LS) of
        {ok, Conn} ->
            {ok, Data} = gen_tcp:recv(Conn, 0, 5000),
            gen_server:cast(request_queue, {request, Data, Conn}),
            self() ! accept,
            {noreply, State};
        {error, _} ->
            self() ! accept,
            {noreply, State}
    end.

The acceptor is a gen_server with a single job. If it crashes, the supervisor restarts it. The listening socket is recreated, and the server continues. No other stage is affected.

Stage 2: The request queue and processor pool

The request queue is a process that buffers incoming requests and distributes them to a pool of processor workers. In a minimal implementation, the queue itself can be a gen_server that holds a bounded list and dispatches to available workers:

-module(request_queue).
-behaviour(gen_server).

handle_cast({request, Data, Conn}, State) ->
    Worker = pick_worker(State),
    gen_server:cast(Worker, {process, Data, Conn}),
    {noreply, State}.

The processor worker parses the HTTP request, generates a response (for the exercise, a simple JSON payload), and enqueues the result for the writer:

-module(processor).
-behaviour(gen_server).

handle_cast({process, Data, Conn}, State) ->
    Response = generate_response(Data),
    gen_server:cast(response_queue, {response, Response, Conn}),
    {noreply, State}.

generate_response(_Data) ->
    Body = <<"{\"status\":\"ok\"}">>,
    <<"HTTP/1.1 200 OK\r\nContent-Type: application/json\r\nContent-Length: ",
      (integer_to_binary(byte_size(Body)))/binary, "\r\n\r\n", Body/binary>>.

The processor pool is where the actual work happens. In a real system, this is where you would add CPU-bound processing, database queries, or calls to downstream services. In the exercise, it is deliberately trivial so that the architecture — not the business logic — is the focus.

Stage 3: The response queue and writer

The writer consumes responses from the response queue and sends them back to the client:

-module(writer).
-behaviour(gen_server).

handle_cast({response, Response, Conn}, State) ->
    gen_tcp:send(Conn, Response),
    gen_tcp:close(Conn),
    {noreply, State}.

Again, one job. One process. One failure domain.

Supervision: the glue that makes it resilient

The entire pipeline is wrapped in an OTP supervision tree. The exact strategy depends on the desired semantics, but a one_for_one supervisor over the three stages is sufficient for the exercise:

init([]) ->
    SupFlags = #{strategy => one_for_one, intensity => 5, period => 10},
    Children = [
        #{id => acceptor, start => {acceptor, start_link, [8080]}},
        #{id => request_queue, start => {request_queue, start_link, []}},
        #{id => processor_sup, start => {processor_sup, start_link, []}},
        #{id => response_queue, start => {response_queue, start_link, []}},
        #{id => writer, start => {writer, start_link, []}}
    ],
    {ok, {SupFlags, Children}}.

This is the payoff of the exercise. In Java, implementing SEDA requires a thread pool per stage, a bounded queue per stage, a rejection policy per queue, and a restart mechanism per stage — all wired together manually. In Erlang, the thread pool is a supervisor, the queue is a mailbox, and the restart mechanism is a supervisor callback. The architecture is the language.

What the exercise actually teaches

The three-stage server is small enough to implement in an afternoon, but it surfaces every decision that matters in a concurrent system:

1. Backpressure is explicit

If the processor pool cannot keep up with the acceptor, the request queue grows. In a real system, you bound the queue and define a rejection policy — {error, overload} or a 503 response. In the exercise, the student sees the queue as a first-class object that can grow, shrink, and overflow. The architecture forces the question: what happens when stage N is slower than stage N−1?

2. Failure isolation is structural

If the processor crashes on a malformed request, only that processor process dies. The acceptor continues accepting. The writer continues writing. The supervisor restarts the processor. The student sees that failure is contained by the topology, not by try/catch blocks scattered through the code.

3. Stages can be scaled independently

In the exercise, the processor pool is a supervisor with N children. To handle more load, increase N. The acceptor and writer remain unchanged. This is the SEDA promise made concrete: each stage is an independent scaling unit.

4. The queue is the control boundary

Because the queues are explicit, the student can see where load accumulates. In a thread-per-request server, there is no queue — there are just threads blocking on I/O. In SEDA, the queue is a named, observable, controllable thing. The architecture makes the system debuggable in a way that thread-per-request systems are not.

From exercise to verification: the next step

The three-stage server is a pedagogical milestone, but it is not the end of the learning arc. Once the student has built a SEDA system in Erlang, the natural next question is: how do I know this is correct?

This is where the verification literature connects. The same stage-and-queue topology that makes the system scalable also makes it verifiable:

ACTORCHESTRA can express cross-stage causal properties — “whenever the acceptor enqueues a request, the writer eventually sends a response” — and monitor them at runtime.
DDMon can detect deadlocks that emerge from synchronous calls between stages, proving soundness and completeness from the outside.
NVLang can enforce protocol conformance at compile time, ensuring that the processor never sends a message the writer cannot handle.

The SEDA exercise is the construction phase. Verification is the assurance phase. Staroletov’s pedagogical arc — refactoring, recursion, processes, supervision, verification — culminates in exactly this: a system that is not only built but provably correct.

Conclusion: architecture as a teaching tool

The ERLDA paper’s contribution is not a novel web server. It is a demonstration that SEDA and Erlang/OTP are conceptually isomorphic — and that this isomorphism can be taught through a small, complete, buildable exercise.

The three-stage HTTP server forces the student to think in terms of queues, stages, failure domains, and supervision. It makes backpressure visible, isolation structural, and scaling explicit. And when the student finishes, they have not just written a server — they have internalized an architecture that applies to every concurrent system they will build afterward.

That is what the best teaching exercises do: they are small enough to finish, and large enough to contain the whole problem.

References:

ERLDA: Areias, Fernando; Neto, Adolfo. “ERLDA: Explorando Concorrência e Resiliência com SEDA em Erlang.” In: I Workshop em Engenharia de Software para Programação Funcional (SE4FP 2025), Recife/PE, pp. 27–32. DOI: 10.5753/se4fp.2025.14570

SEDA (original): Welsh, Matt; Culler, David; Brewer, Eric. “SEDA: An Architecture for Well-Conditioned, Scalable Internet Services.” ACM SIGOPS Operating Systems Review, Vol. 35, No. 5, 2001.

Pedagogical context: Staroletov, Sergey. “Modern Erlang Teaching from Code Refactoring to Actor System Verification.” Erlang Workshop 2026. DOI: 10.1145/3830434.3830946

Code: github.com/fernandoareias/web-server-erl

Have you built a SEDA-style system in Erlang — or tried to port the architecture to another runtime? What was the hardest part to get right? Let me know in the comments.

Verifying Actor Systems: Beyond Testing

Matheus de Camargo Marques — Thu, 05 Nov 2026 12:14:08 +0000

Verifying Actor Systems: Beyond Testing

Actor systems are notoriously difficult to verify through traditional testing. Message ordering is non-deterministic, properties often span multiple actors, and a protocol violation that only manifests under a specific interleaving can hide in production for months.

The 2025–2026 literature offers three complementary answers to this problem, each attacking a different layer of the verification stack: runtime verification of causal properties, formal deadlock detection from the outside, and static protocol typing at compile time. Together, they sketch a path from “we tested it and it seemed fine” to “we have evidence that it is correct.”

This article breaks down all three — and connects them back to the pedagogical argument that Erlang’s supervision model is not a set of APIs to memorize, but a set of contracts to understand.

Why testing actor systems is not enough

A unit test checks one process in isolation. An integration test checks a few processes under a specific schedule. But an actor system’s behaviour depends on which messages arrive in which order — and the number of possible interleavings grows combinatorially with the number of actors.

Worse, the properties we actually care about are often cross-actor:

“Whenever the order actor confirms a purchase, the inventory actor must have received a reservation first.”
“If a service sends a request, it eventually receives a response — or is provably deadlocked.”
“No process ever sends a message that violates its declared protocol.”

None of these can be verified by testing a single process. They require either observing the running system or proving properties before it runs.

The three approaches below take one of those two paths.

1. Runtime verification: ACTORCHESTRA and WALTZ

ACTORCHESTRA is a runtime verification framework for Erlang that automatically tracks causality across multi-actor interactions. It was presented at the 2026 IEEE International Conference on Software Testing, Verification and Validation (ICST) in the paper “In Perfect Harmony: Orchestrating Causality in Actor-Based Systems.”

The core problem it solves is stated precisely in the abstract: “Properties frequently span multiple actors with complex causal dependencies, while non-deterministic message interleavings can obscure execution semantics. Moreover, most existing monitoring tools are designed for single-process behavior.”

ACTORCHESTRA addresses this in two parts:

Targeted code injection into Erlang systems that follow OTP guidelines — establishing the orchestration infrastructure needed to track causal relationships without manual modification of the target system.
WALTZ, a specification language that compiles multi-actor properties into executable Erlang monitors that integrate with the instrumented system.

A concrete property you can express in WALTZ:

“Whenever the order actor sends a confirmation message to the customer actor, the inventory actor must have received a reservation message beforehand.”

This is a causal chain — not a simple state predicate. ACTORCHESTRA monitors the chain at runtime and alerts when the property is violated. Three case studies demonstrate its effectiveness in detecting complex behavioural violations in real-world actor systems.

The trade-off is explicit: the paper quantifies the runtime overhead of the monitoring infrastructure and analyses the balance between added safety guarantees and execution costs. Runtime verification is not free — but it catches violations that no unit test would ever see.

2. Formal deadlock detection: DDMon

DDMon (2025, OOPSLA) takes a different tack: instead of instrumenting the system’s source code, it deploys distributed black-box monitors alongside each service and detects deadlocks by only observing incoming and outgoing messages, exchanging probes with other monitors.

The formal contribution is significant:

A formal model that captures RPC-based application styles — including gen_server processes in Erlang/OTP.
A distributed black-box monitoring algorithm proven sound (no false positives) and complete (no false negatives).
A Coq mechanisation of the results.

This is the first work that formalises, proves the correctness of, and implements distributed black-box monitors for deadlock detection.

The DDMon tool implements these monitors for Erlang and Elixir applications based on gen_server, with minimal user intervention. It also optionally collects logs via the Erlang/OTP trace mechanism and visualises them to help diagnose deadlocks.

Why black-box matters: the monitoring does not depend on the internal syntax of the services — the process internals are not observable by the monitors. You can attach DDMon to a running system without modifying it, and trust its verdict because the algorithm was proven correct.

For practitioners, the message is direct: if you have gen_server processes making chained synchronous calls — a common microservices pattern — DDMon can tell you when they are deadlocked, and its answer is mathematically guaranteed.

3. Static protocol typing: NVLang

Both ACTORCHESTRA and DDMon operate on a running system. NVLang moves the verification to compile time.

Erlang has no static guarantees about message protocols. Processes communicate by sending arbitrary messages that are filtered by pattern matching at runtime — which means protocol violations are deferred to production failures.

NVLang is a statically typed functional language that compiles to Core Erlang, preserving interoperability with the existing ecosystem. Its central contribution is that algebraic data types (ADTs) naturally encode actor protocols: each actor declares the sum type representing its message vocabulary, and the type system enforces protocol conformance at compile time.

Two further constructs complete the picture:

Typed process identifiers (Pid[T]) encode the protocol an actor expects.
Typed futures (Future[T]) provide type-safe request-reply patterns.

By extending Hindley–Milner type inference to track message protocols, NVLang eliminates an entire class of message-passing errors while keeping syntax clean. The type system is formalised with proof sketches for type soundness, demonstrating that well-typed NVLang programs cannot send messages that violate actor protocols.

NVLang is a separate language, but its concepts discipline pure Erlang design. Before implementing a gen_server, define the sum type of messages it accepts. That single act of specification reduces the class of errors that would otherwise only manifest in production.

How the three fit together

The three approaches are not competitors. They occupy different points in the verification timeline:

Approach	When it runs	What it catches	What it costs
NVLang	Compile time	Protocol violations, malformed messages	Requires writing in a new language (or disciplining design)
ACTORCHESTRA	Runtime	Cross-actor causal violations	Monitoring overhead
DDMon	Runtime	Distributed deadlocks	Probe exchange overhead

A mature verification strategy uses all three:

Before deployment, use static typing (or its design discipline) to eliminate protocol-level bugs.
At runtime, use ACTORCHESTRA to monitor causal properties that no type can express.
Continuously, use DDMon to detect deadlocks that emerge from the interaction of otherwise-correct services.

The academic connection: verification as the end of a pedagogical arc

This literature connects directly to Staroletov’s 2026 Erlang Workshop paper, “Modern Erlang Teaching from Code Refactoring to Actor System Verification.” The course it describes moves students from refactoring imperative code, through Taylor-series recursion, to lightweight processes, and finally to verification of actor systems with Promela/SPIN.

The progression matters. Verification is not taught as an isolated topic — it is the culmination of learning to reason about concurrent behaviour. Students who have refactored away imperative sequencing, internalised pattern matching as type-driven dispatch, and built systems with supervision trees are ready to ask: “How do I know this is correct?”

ACTORCHESTRA, DDMon, and NVLang are three answers to that question. Each makes a different trade-off between when verification happens and what it guarantees. Staroletov’s pedagogical point — that Erlang’s model is a set of contracts to understand, not APIs to memorize — applies equally to verification: the goal is not to run a tool, but to know what property you are checking and why.

Conclusion: from “it seems fine” to “we have evidence”

Actor systems are too concurrent and too non-deterministic to verify by testing alone. The 2025–2026 literature offers a layered answer:

NVLang proves protocol correctness at compile time.
ACTORCHESTRA monitors causal properties across actors at runtime.
DDMon proves deadlock freedom from the outside, with soundness and completeness guarantees.

Together, they move the field from “we tested it and it seemed fine” to “we have evidence that it is correct.”

For anyone building or teaching actor systems, the lesson is clear: verification is not a luxury bolted on after the system works. It is the final stage of learning to reason about concurrency — and the tools now exist to make it practical.

References:

ACTORCHESTRA / WALTZ: “In Perfect Harmony: Orchestrating Causality in Actor-Based Systems.” IEEE ICST 2026. IEEE Xplore

DDMon: Rowicki, Francalanza, Scalas. “Correct Black-Box Monitors for Distributed Deadlock Detection: Formalisation and Implementation.” PACMPL (OOPSLA 2025). DOI: 10.1145/3763069

NVLang: Guerreiro et al. “NVLang: Unified Static Typing for Actor-Based Concurrency on the BEAM.” arXiv:2512.05224, Dec 2025. arXiv

Pedagogical context: Staroletov, Sergey. “Modern Erlang Teaching from Code Refactoring to Actor System Verification.” Erlang Workshop 2026. DOI: 10.1145/3830434.3830946

Have you used runtime verification, deadlock monitoring, or static typing in a production actor system? What did it actually catch — and what did it miss? Let me know in the comments.

OTP Supervision Is Not a Pattern You Can Copy: Lessons from Supervision Without Blocking (2026)

Matheus de Camargo Marques — Thu, 05 Nov 2026 12:11:40 +0000

OTP Supervision Is Not a Pattern You Can Copy: Lessons from Supervision Without Blocking (2026)

Actor frameworks for Rust, the JVM, and .NET all advertise “Erlang/OTP-style supervision.” It has become a headline feature, a selling point, a box to check. But a 2026 paper by Sam Uwejan and Erdogan Dogdu (Angelo State University), Supervision Without Blocking: An Evidence-Driven Redesign of OTP-Style Fault Tolerance for Cooperative Runtimes, delivers an uncomfortable finding: many of those implementations inherit OTP’s semantics without understanding the contracts that make them work — and that gap produces real, catalogued defects .

This article unpacks what the paper found, why OTP’s supervision guarantees are harder to port than they look, and what it means for anyone building fault-tolerant systems outside the BEAM.

The audit: 24 defect classes, one root cause

Uwejan and Dogdu did not set out to criticize ports. They set out to audit every supervision guarantee against OTP’s own documentation and source code, read verbatim at pinned versions, and then against the source of three further Rust actor frameworks at fixed revisions . Blind adversarial audits and the cross-framework study surfaced 24 distinct defect classes .

The striking result is not the number. It is the concentration: eight of the 24 defect classes reduce to a single root cause — “reconstructing, by explicit mechanism, the atomicity a synchronous supervisor gets implicitly” .

In other words: the ports copied the shape of OTP supervision without copying the substrate that makes the shape consistent.

Why OTP supervision works: the blocking supervisor

An OTP supervisor is a single-threaded process. It blocks for the duration of every restart and termination step it performs. Its consistency contracts — the guarantees that make “let it crash” safe — are silent consequences of that blocking .

Consider what this means concretely. When an OTP supervisor restarts a child:

It receives the exit signal.
It synchronously terminates the remaining children according to the shutdown strategy.
It synchronously starts the new child.
It only then returns to its message loop.

Because the supervisor is single-threaded and blocked, no other lifecycle message can interleave with those steps. The atomicity is not enforced by locks or transactions. It is a natural consequence of the supervisor doing one thing at a time and not processing its mailbox until that thing is done.

This is the contract that ports miss. A cooperative runtime like Tokio has an asynchronous scheduler. To keep the supervisor responsive, frameworks drop the blocking . But once the supervisor no longer blocks, the atomicity disappears — and the port must reconstruct it explicitly, or inherit the absence as “unexamined risk” .

The unpaid price: push-based lifecycle signaling

The paper identifies a second pattern across all four examined codebases: they independently adopted push-based lifecycle signaling, “whose losses and reorderings are the unpaid price of an asynchronous supervisor” .

In a blocking supervisor, lifecycle events are processed in order because the supervisor processes one message at a time. In an asynchronous supervisor, lifecycle signals are pushed to the supervisor while it may be busy doing something else. Signals can be lost under backpressure. They can be reordered relative to ordinary messages. And the supervisor may make decisions based on a lifecycle state that has already changed.

These are not hypothetical bugs. They are structural consequences of removing the blocking without replacing the atomicity it provided.

The redesign: paying for the trade deliberately

Uwejan and Dogdu do not argue that blocking is the only correct design. They argue that the trade must be priced. Their proposed runtime, ANON, closes all 24 catalogued defect classes through three mechanisms :

Supervisor-owned completion values. Instead of pushing lifecycle signals to the supervisor and hoping they arrive in order, the supervisor holds each child’s completion as a value returned by a task set it owns. Completion is pulled, not pushed — and pulling from an owned set preserves ordering by construction.
Per-incarnation identity. Every process instance carries an identity drawn from a monotonic counter. A late signal from a previous incarnation cannot be mistaken for a signal from the current one.
A single lifecycle state machine. All liveness bookkeeping collapses into one state machine with a single transition function. There are no ad-hoc flags to fall out of sync.

The result is validated by 241 tests, including regression reproductions that were verified to fail against pre-fix code by temporarily reverting the fix, then re-applied and observed to pass across 10 runs .

What ANON adds — and what it cannot

ANON holds OTP’s verbatim-verified contracts while adding two properties OTP does not offer :

A supervisor that remains responsive throughout group restarts. Because it never blocks, it can answer status queries and manual commands even while a restart group is in progress.
Message handlers that are never cancelled mid-execution. On the BEAM, an untrappable kill can arrive preemptively. ANON declines to imitate that, because cancelling a handler mid-execution drops local state at an arbitrary await point and exports a cancellation-safety obligation into every user handler .

But the paper is careful about the forcing boundary. Erlang’s kill is guaranteed by a virtual machine the language owns. An in-process runtime on a host language owns neither the scheduler nor the process. Its strongest primitive is task abort at a yield point. A handler that never yields defeats both the signal and the abort backstop. And an operating-system kill of the host runs no teardown at all .

This is the honest limit of any OTP-style supervision built outside the BEAM: some guarantees cannot be reconstructed, because the substrate does not permit them.

The academic connection: why this matters for teaching and for engineering

This paper connects directly to the pedagogical work of Staroletov (2026), which emphasizes that Erlang’s supervision model is not a set of APIs to be memorized but a set of contracts to be understood. The course described in that paper moves students from simple processes to OTP supervision to verification, treating each step as an exercise in reasoning about consistency, not just syntax.

Supervision Without Blocking makes the same point from the engineering side. Frameworks that copy the OTP style without evaluating which guarantees deserve keeping are not implementing supervision. They are implementing a resemblance of supervision . The 24 defect classes are the cost of that resemblance.

The lesson is not “never port OTP.” The lesson is: if you port it, you must reconstruct the atomicity explicitly — and you must know which guarantees your runtime can actually honor.

What this means for practitioners

If you are building on the BEAM, this paper reinforces a simple principle: use native OTP. The synchronous supervisor is not a legacy constraint. It is the mechanism that makes the consistency contracts true. Replacing it with an asynchronous variant inside Erlang would require the same reconstruction ANON performs — and OTP already does it correctly.

If you are evaluating an actor framework on another runtime, ask three questions:

What happens to lifecycle signals under backpressure? If the answer involves “push” without an owned completion value, ordering is not guaranteed.
How does the framework distinguish incarnations? Without per-incarnation identity, a late signal from a dead process can be mistaken for a live one.
What atomicity does the supervisor provide? If the supervisor is asynchronous and does not explicitly reconstruct atomicity, the consistency contracts are not the same as OTP’s — regardless of what the README says.

The paper’s contribution is to make those questions askable, with evidence behind each answer.

Conclusion: contracts, not cosmetics

OTP supervision looks simple. A supervisor starts children, restarts them when they die, and escalates when it cannot recover. The simplicity is real — but it is earned by a runtime that blocks. Ports that remove the blocking without replacing the atomicity are not simplifying supervision. They are removing the foundation and hoping the building stays up.

Uwejan and Dogdu’s audit shows what happens when it does not. The 24 defect classes are not exotic edge cases. They are the predictable consequences of copying a pattern without its substrate. And the fix is not a patch — it is a redesign that treats every guarantee as a design decision that must earn its place.

That is a lesson that applies far beyond Erlang.

Main reference: UWEJAN, Sam; DOGDU, Erdogan. Supervision Without Blocking: An Evidence-Driven Redesign of OTP-Style Fault Tolerance for Cooperative Runtimes. arXiv:2610.34521 [cs.DC], 25 Oct 2026. Available at: https://arxiv.org/abs/2610.34521

Related pedagogical context: STAROLETOV, Sergey. Modern Erlang Teaching from Code Refactoring to Actor System Verification. In: Proceedings of the 25th ACM SIGPLAN International Workshop on Erlang (Erlang ‘26), 2026. DOI: 10.1145/3830434.3830946

Have you evaluated an “OTP-style” framework on a non-BEAM runtime? What guarantees did it actually provide — and what did you have to reconstruct yourself? Let me know in the comments.

Erlang Actors vs Java Virtual Threads: What Staroletov (2026) Teaches Us About Concurrency Design

Matheus de Camargo Marques — Thu, 05 Nov 2026 12:08:23 +0000

Erlang Actors vs Java Virtual Threads: What Staroletov (2026) Teaches Us About Concurrency Design

Java finally has lightweight threads. Erlang has had them since 1986. But the gap between the two is not about raw concurrency numbers — it is about what happens when things go wrong.

In his 2026 Erlang Workshop paper “Modern Erlang Teaching from Code Refactoring to Actor System Verification,” Sergey Staroletov draws a direct contrast between Erlang’s actor model and Java’s modern virtual threads (Project Loom). His point is not that one is faster. It is that both enable high concurrency, but only one bakes fault isolation and hierarchical supervision into the language design from the ground up.

This article unpacks that contrast — and why it matters for anyone choosing a concurrency model today.

The concurrency renaissance

For decades, the standard answer to “I need more concurrency” was “spawn more OS threads.” That answer collapsed under its own weight:

Each OS thread reserves 1–8 MB of stack by default.
Context switching costs microseconds and pollutes CPU caches.
Ten thousand threads is already a struggle on commodity hardware.

Two independent communities attacked this problem from opposite directions:

Java kept the thread abstraction but made it cheap. Project Loom (finalized in JDK 21) introduced virtual threads: JVM-managed threads multiplexed onto a small pool of carrier threads.
Erlang never had heavyweight threads to begin with. The BEAM virtual machine has always scheduled processes — not OS threads — in user space, with preemption based on reduction counts.

On paper, both now support millions of concurrent units of execution. So why does Staroletov insist the models are fundamentally different?

What Java virtual threads actually are

A virtual thread in Java is a Thread object backed by the JVM rather than the OS. When a virtual thread blocks on I/O, the JVM unmounts it from its carrier thread and parks it on the heap. The carrier is freed to run another virtual thread.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 1_000_000).forEach(i ->
        executor.submit(() -> {
            Thread.sleep(Duration.ofSeconds(1));
            return i;
        })
    );
}

This is a genuine leap forward. A million virtual threads sleeping for one second complete in roughly one second — not a million. The API is familiar: it is still Thread, still Runnable, still ExecutorService. Migration cost is near zero.

But look closely at what a virtual thread is: it is a task, not an actor. It does not have a mailbox. It does not have a PID. It cannot receive messages from another thread without an external queue. It shares mutable memory with every other thread in the JVM. And when it throws an uncaught exception, that exception propagates to whatever submitted it — usually an ExecutorService, which may swallow it, log it, or hand it to an UncaughtExceptionHandler you forgot to configure.

Virtual threads make threads cheap. They do not make failure cheap.

What Erlang processes actually are

An Erlang process is not a thread. It is a first-class language construct with three properties baked into the runtime:

Its own mailbox — a queue of messages, addressed by PID.
Its own heap — no shared mutable state with any other process.
Its own failure domain — a crash in one process does not corrupt another.

-module(counter).
-export([start/0, increment/1, get/1]).

start() ->
    spawn(fun() -> loop(0) end).

loop(N) ->
    receive
        {increment, From} ->
            From ! {ok, N + 1},
            loop(N + 1);
        {get, From} ->
            From ! {value, N},
            loop(N)
    end.

increment(Pid) ->
    Pid ! {increment, self()},
    receive {ok, New} -> New end.

get(Pid) ->
    Pid ! {get, self()},
    receive {value, N} -> N end.

The memory math is the headline number Staroletov cites: an Erlang process costs about 326 words — roughly 2.6 KB on a 64-bit system. Not kilobytes of stack. Not megabytes of reserved memory. A few kilobytes of heap and a small control block. A single BEAM node can hold millions of these comfortably.

The BEAM scheduler runs entirely in user space. It preempts processes based on a reduction count — a measure of work done, not wall-clock time — which means a process cannot starve others by running a tight loop. No OS involvement, no thread priorities, no priority inversion.

But the real story is not the memory. It is what happens when one of those processes crashes.

The real difference: fault isolation

Here is the same failure scenario in both models.

Java virtual thread:

executor.submit(() -> {
    var conn = socket.accept();
    var data = parse(conn);   // throws ParseException
    process(data);
});

The ParseException unmounts the virtual thread. The exception is captured by the Future returned from submit(). If nobody calls future.get(), the exception is silently lost. If the task was submitted to a shared executor, the executor may log it — or may not, depending on configuration. Meanwhile, the socket is leaked, the conn is leaked, and any state partially written during parse() is now inconsistent.

To handle this properly, you need:

A try/catch around every task body.
A resource-management strategy (try-with-resources around conn).
A policy for what to do with the failed task (retry, log, alert).
A strategy for restarting the failed component.

Erlang process:

handle_conn(Socket) ->
    case gen_tcp:accept(Socket) of
        {ok, Conn} ->
            case parse(Conn) of
                {ok, Data} -> process(Data);
                {error, Reason} -> exit({parse_failed, Reason})
            end;
        {error, Reason} ->
            exit({accept_failed, Reason})
    end.

If parse/1 crashes, the process dies. Its mailbox is discarded. Its heap is garbage-collected as a unit. The socket is closed by the runtime because the process that owned it is gone. Nothing else in the system is affected.

And critically: a supervisor is watching.

Hierarchical supervision: OTP as a design pattern

Erlang’s “let it crash” philosophy is not about ignoring failures. It is about making failures local and recoverable through a supervision tree.

-module(conn_sup).
-behaviour(supervisor).
-export([start_link/0, init/1]).

start_link() ->
    supervisor:start_link({local, ?MODULE}, ?MODULE, []).

init([]) ->
    SupFlags = #{strategy => one_for_one,
                 intensity => 5,
                 period => 10},
    ChildSpec = #{id => conn_handler,
                  start => {conn_handler, start_link, []},
                  restart => permanent,
                  shutdown => 5000,
                  type => worker},
    {ok, {SupFlags, [ChildSpec]}}.

This supervisor says: “If the conn_handler worker dies, restart it. If it dies more than five times in ten seconds, escalate to my own supervisor — because something is fundamentally wrong.”

That is the entire failure-handling story: one line of configuration replaces pages of Java exception-handling boilerplate. The supervisor tree is not an afterthought bolted onto the runtime. It is the runtime’s organizing principle.

Java has no equivalent in the language. You can build one — libraries like Akka do exactly this — but you are building it on top of a runtime that was not designed for it. Staroletov’s point is that this difference is not incidental. It is architectural.

What virtual threads do not give you

To be fair to Project Loom, it solves the problem it was designed to solve: thread-per-request scalability without rewriting blocking code. That is a massive win for the Java ecosystem, and Staroletov acknowledges it.

But the comparison he draws is deliberately precise. Virtual threads give you:

Cheap concurrency.
Familiar Thread API.
Seamless integration with existing java.util.concurrent.

They do not give you:

Isolated failure domains. A virtual thread shares the JVM heap with every other thread. A StackOverflowError or OutOfMemoryError takes down the whole process, not one task.
Mailboxes. Communication is still through shared memory or external queues, not first-class message passing.
Supervision trees. Failure recovery is an application-level concern, not a runtime primitive.
Location transparency. A virtual thread cannot send a message to a thread on another node without a serialization layer you write yourself.

Erlang gives you all four as language features. That is the difference Staroletov is pointing at.

The pedagogical angle

The contrast appears in Staroletov’s course at a specific moment. After students have refactored imperative Erlang into functional Erlang, and after they have written recursive functions with multiple accumulators, the course introduces lightweight processes through a live demonstration: a TCP server handling thousands of simultaneous connections on modest hardware.

The pedagogical payoff is the memory comparison. When students see that an Erlang process costs 2.6 KB while an OS thread costs megabytes, the actor model stops being an abstract concept and becomes a concrete engineering trade-off. When they then see a supervisor restart a crashed worker automatically, the “let it crash” philosophy stops being a slogan and becomes a design pattern they can reason about.

The Java comparison enters as a foil, not as a competitor. Staroletov uses modern Java virtual threads to show that high concurrency is now table stakes. What is not table stakes — what still requires deliberate architectural choices in Java — is fault isolation and hierarchical supervision. Erlang gives them to you on day one because the language was designed around them.

So which should you use?

The honest answer is: it depends on what you are building.

You need…	Lean toward
Millions of blocking I/O tasks, existing Java codebase	Java virtual threads
Fault-tolerant distributed systems, telecom-grade uptime	Erlang/OTP
Shared-memory parallelism on large datasets	Java (or any JVM language)
Location transparency and hot code reloading	Erlang/OTP
Familiar tooling, huge library ecosystem	Java
Supervision trees as a first-class primitive	Erlang/OTP

Virtual threads are a concurrency primitive. Erlang processes are a system architecture. They are not competing answers to the same question — they are answers to different questions that happen to overlap.

Staroletov’s contribution is to make that distinction visible to students before they commit to a mental model. That is what good teaching does: it does not tell you which tool to use. It tells you what each tool is actually for.

Conclusion

Java virtual threads closed the concurrency gap. They did not close the fault-tolerance gap. Erlang’s actor model offers something virtual threads structurally cannot: failure as a first-class, isolatable, supervisable event — not an exception that escapes to an executor.

Staroletov (2026) uses this contrast not to declare a winner, but to sharpen a pedagogical point. When students see both models side by side, they stop asking “which is faster?” and start asking “what kind of failure do I want my system to survive?” That is the question that actually determines the architecture.

Main reference: STAROLETOV, Sergey. Modern Erlang Teaching from Code Refactoring to Actor System Verification. In: Proceedings of the 25th ACM SIGPLAN International Workshop on Erlang (Erlang ‘26), 2026. DOI: 10.1145/3830434.3830946

Have you migrated a Java service to virtual threads, or an Erlang service to something else? What surprised you about the failure semantics? Let me know in the comments.

From `if` to `verify`: How to Actually Teach Erlang (from Refactoring to Actor System Verification)

Matheus de Camargo Marques — Thu, 05 Nov 2026 11:51:12 +0000

From `if` to `verify`: How to Actually Teach Erlang (from Refactoring to Actor System Verification)

Teaching Erlang is easy. The hard part is getting students to think in Erlang.

Anyone who has taught functional programming to students coming from C, Java, or Python knows the obstacle: the student writes Erlang with a Java accent. They use commas as statement separators, if as a control-flow construct, temporary variables for everything, and at the end they ask: “Professor, why doesn’t this feel functional?”

The paper “Modern Erlang Teaching from Code Refactoring to Actor System Verification” by Sergey Staroletov (Polzunov Altai State Technical University), presented at the Erlang Workshop 2026 (co-located with ICFP), synthesizes years of experience teaching Erlang in a Master’s program in Software Engineering and proposes a methodological progression that goes from refactoring imperative code all the way to formal verification of actor systems with Promela/SPIN.

In this article, I’ll break down that progression and show why it works in practice.

The problem: the “imperative accent” in Erlang code

The typical Erlang student already knows how to program in imperative languages. They are used to sequential execution, mutable state, and explicit control flow. When they write Erlang, they reproduce those patterns:

process_one(Parent, [First|Next]) ->
    FullName = Parent ++ "/" ++ First,
    IsDir = filelib:is_dir(FullName),
    if
        IsDir == true -> recurser(FullName);
        IsDir == false -> io:format(FullName ++ "~n"), process_one(Parent, Next)
    end;
process_one(_, []) -> ok.

This code works, but it violates the principles of functional style: there are commas separating “commands,” an imperative if, and temporary variables that create hidden temporal dependencies. The compiler cannot safely reorder those expressions, and the student does not see the benefits in parallelization and testability that the functional paradigm offers.

Staroletov’s proposal is to systematically refactor this code until commas as sequential operators are eliminated and replaced by function composition.

Step 1: Refactoring — eliminate the commas

The goal is to transform the body of each function into a single expression, composed of calls to smaller functions.

The methodology has five steps applied to the original code:

Isolate side effects (I/O, process dictionary access, file writes).
Introduce intermediate functions for each expression evaluated sequentially.
Pass the result of the previous evaluation as a parameter to the next function, instead of storing it in a temporary variable.
Replace if with pattern matching (different function clauses for different guards or types).
Eliminate code duplication by moving repeated computations into separate functions and then composing them.

Applied to the example:

%% Step 1: isolate construction of the full name
construct(Parent, First) -> Parent ++ "/" ++ First.

%% Steps 2 and 3: eliminate FullName and IsDir by passing the result forward
process_by_dir(true, FullName) -> recurser(FullName);
process_by_dir(false, FullName) -> io:format(FullName ++ "~n").

%% Step 4: pattern matching instead of if
process_construct(Parent, First) ->
    Full = construct(Parent, First),
    process_by_dir(filelib:is_dir(Full), Full).

%% Step 5: compose everything
process_one(Parent, [First|Next]) ->
    process_construct(Parent, First),
    process_one(Parent, Next);
process_one(_, []) -> ok.

The final code is a chain of compositions and accumulator recursion. There are no commas separating “commands” — only expressions that compose.

Why does this work pedagogically? Because the student sees the transformation happen. They do not receive a ready-made solution; they refactor the code they wrote themselves, step by step, until the functional style emerges naturally.

Step 2: Recursion with Taylor series — breaking the factorial/Fibonacci mold

After refactoring, the next challenge is recursion. The classic examples — factorial, Fibonacci, list sum — are useful, but they do not reveal the depth of recursive thinking.

Staroletov proposes computing sine via the Taylor series (Maclaurin):

sin x = x - \frac{x ^{3}}{3 !} + \frac{x ^{5}}{5 !} - \frac{x ^{7}}{7 !} + \dots

The student implements a recursive function that accumulates two parameters: the partial sum and the current term, with two stopping criteria — precision

ϵ

and a maximum number of iterations.

sin_n(X, Sum, Current, I, IMax, EPS)
  when IMax > 0, abs(Current) < EPS ->
    Sum + Current;
sin_n(_X, Sum, Current, I, IMax, _EPS)
  when I >= IMax ->
    Sum + Current;
sin_n(X, Sum, Current, I, IMax, EPS) ->
    sin_n(X,
          Sum + Current,
          Current * (-1.0 * X * X / ((2 * I) * (2 * I + 1))),
          I + 1,
          IMax,
          EPS).

sin_e(X) -> sin_n(X, 0.0, X, 1, 100, 0.00001).

This activity forces the student to:

accumulate more than one parameter (sum and current term), expanding the concept of an accumulator;
compute the recurrence factor correctly;
handle two stopping criteria (protection against divergent series);
understand numerical limitations (for large $∣ x ∣$
, the series converges slowly, requiring argument reduction).

The method is reinforced with other problems that use the same scheme — computing

π

, computing

e

, manipulating lists without using the ready-made functions from the lists module — and each function must be accompanied by unit tests with EUnit.

Step 3: Lightweight processes — the “wow” that changes perspective

After consolidating the functional core, the course introduces the actor model. The paper highlights an impactful demonstration: a TCP server in Erlang that handles thousands of simultaneous connections on modest hardware, briefly compared with modern Java virtual threads.

The pedagogical point is the order of magnitude: Erlang processes use about 326 words of memory (2.6 KB on 64-bit), versus 1–8 MB per operating-system thread. The BEAM scheduler runs in user space, preempting processes based on reduction counts. The student sees in practice why the actor model scales where traditional threads collapse.

Step 4: Verification — Promela as a logical continuation of the actor model

Here is the most interesting methodological differentiator in the paper. Instead of treating formal verification as a separate and “scary” topic, Staroletov presents it as a natural continuation of studying actors.

The idea is simple: if the student already thinks in terms of processes, channels, and message passing, they already have the mental framework to model those same concepts in Promela and verify them with SPIN.

The mapping is almost direct:

Erlang processes → Promela processes;
PIDs → dedicated channels between processes (since Promela has no direct equivalent to PIDs);
message send/receive → channel operations (! and ?).

The student formulates LTL properties and verifies them in SPIN. The basic set includes:

Property	LTL formula
Absence of deadlock	Checked automatically by SPIN
Reachability	$⋄ (msgRcv = 1)$
Safety (“message never sent before connection”)	$□ (\neg (msgSent \land \neg connected))$
Liveness (“if sent, eventually received”)	$□ (msgSent \to ⋄ msgRcv)$
Absence of unauthorized states	$□ (\neg bug)$

SPIN builds the automaton and returns either “no errors” or a counterexample with the sequence of transitions that violates the property. The classic teaching example is a modified ping-pong: the Pong process sends a request to the Right process before replying, but Right “forgets” to respond. The property “every ping results in a pong” is violated, and the counterexample shows Pong waiting forever.

The student then sees the bug happen in the simulator — and understands why verification is not an academic luxury, but part of engineering culture: “it is not enough to write the system; you must analyze it and prove its properties.”

Step 5: The end-to-end lab — a system that evolves

All these topics are not isolated exercises. The course ties them together in a single lab cycle, in which students develop the same distributed system throughout the semester:

They start with simple processes;
Evolve to OTP supervision;
Integrate Java via JInterface (to demonstrate the contrast between Erlang’s declarative style with pattern matching and Java code loaded with object transformations);
Add a case study of a simplified PoET consensus protocol;
Verify the model in Promela/SPIN;
Optionally port it to Cloud Haskell.

This continuity is powerful: the student does not see “refactoring,” “recursion,” “actors,” and “verification” as disconnected subjects. They see a system growing — and each new technique solves a real problem that emerges from that evolution.

Bonus: Erlang in the age of generative AI

The paper also addresses a contemporary challenge: how do you teach programming when the student can ask ChatGPT for code?

Staroletov’s answer is methodological, not prohibitive: live coding and incremental code construction as a counterpoint to the uncritical use of AI-generated code. The student needs to see the code being built, understand every transformation, every design decision, every refactoring. The focus is not the final product, but the reasoning process that leads to it.

Interestingly, verification in Promela benefits from this as well: even if the student uses AI to translate Erlang code into Promela, they still have to do the manual work of defining LTL properties, interpreting counterexamples, and adjusting the model. AI can accelerate the mechanical part, but it does not replace engineering judgment.

Conclusion: a progression that respects the student’s cognition

What makes this approach remarkable is not only the content — refactoring, Taylor series, lightweight processes, Promela — but the order in which everything appears. Each stage prepares the cognitive ground for the next:

Refactoring eliminates the imperative habit and forces the student to think in terms of composition.
Mathematical recursion expands the repertoire beyond trivial examples.
Lightweight processes provide the practical reward: “look at what this model enables.”
Verification in Promela crowns the structure: the student discovers that they can prove properties about the system they built.

It is a progression that goes from “how to write” to “how to think,” and from “how to think” to “how to guarantee it is correct.”

For anyone teaching Erlang — or any functional language with an actor model — Staroletov’s paper is essential reading. Not because it presents new tools, but because it organizes decades of pedagogical wisdom into a coherent path, tested in the classroom and grounded in the cognitive reality of students.

Main reference: STAROLETOV, Sergey. Modern Erlang Teaching from Code Refactoring to Actor System Verification. In: Proceedings of the 25th ACM SIGPLAN International Workshop on Erlang (Erlang ‘26), 2026. DOI: 10.1145/3830434.3830946

If you have ever taught Erlang (or learned it), what was the biggest cognitive “click” in your journey? Let me know in the comments.

Practical Erlang/OTP Tutorial Based on Recent Academic Evidence (2025–2026)

Matheus de Camargo Marques — Tue, 03 Nov 2026 13:50:47 +0000

Practical Erlang/OTP Tutorial Based on Recent Academic Evidence (2025–2026)

Based on an in-depth search of recent academic articles (2025–2026), I have prepared a practical Erlang/OTP tutorial. The material integrates the main findings from the literature: from refactoring imperative code into the functional paradigm to formal verification of actor systems and the redesign of supervision mechanisms for cooperative runtimes. The tutorial is structured in progressive stages, each grounded in academic evidence.

1. Why Erlang? The Academic Rationale

Modern distributed systems require reliability, scalability, and fault tolerance. Classical imperative languages, with shared memory and explicit threads, often prove inadequate for systems designed for thousands of nodes and millions of concurrent connections. The functional paradigm, which discourages mutable state, offers a cleaner path to parallelization.

Erlang occupies a special place among functional languages because it directly implements the actor model proposed at MIT in the 1970s. In this model, a system consists of processes (actors) that interact exclusively through asynchronous messages. Each actor has a unique address (PID), can create other actors, send messages, and change its behavior. Unlike CSP (Communicating Sequential Processes), which uses synchronous channels, the actor model is better suited to fully decentralized and fault-tolerant systems.

A crucial technical differentiator is memory cost: Erlang’s lightweight processes consume only about 326 words (approximately 2.6 KB on 64-bit systems), compared with 1–8 MB per operating system thread — three orders of magnitude less. This allows the BEAM VM to manage millions of simultaneous processes with efficient resource use.

Supporting reference: STAROLETOV, Sergey. Modern Erlang Teaching from Code Refactoring to Actor System Verification. In: Proceedings of the 25th ACM SIGPLAN International Workshop on Erlang (Erlang '26), 2026. This article synthesizes years of experience teaching Erlang and proposes a methodological progression that goes from refactoring imperative code to verifying actor systems.

2. First Steps: Refactoring from Imperative to Functional

The biggest obstacle for beginners in Erlang is not syntax, but the cognitive shift from imperative to functional thinking. An effective technique proposed in the literature is systematic refactoring of imperative code, eliminating sequential operators (the “commas”) and replacing them with recursion and pattern matching.

Exercise 1: From an imperative loop to a recursive function

Consider the following Java (or Python) code that calculates the sum of the first ( N ) integers:

int sum = 0;
for (int i = 1; i <= N; i++) {
    sum += i;
}
return sum;

In Erlang, the same logic is expressed with tail recursion and pattern matching:

-module(sum).
-export([sum/1]).

sum(N) -> sum(N, 0).

sum(0, Acc) -> Acc;
sum(N, Acc) when N > 0 ->
    sum(N - 1, Acc + N).

The function sum/2 is tail-recursive: the recursive call is the last operation, allowing the BEAM compiler to optimize it into an efficient loop without stack growth.

Academic connection: Staroletov’s article (2026) reports that this approach — removing the “comma mindset” and introducing recursion through Taylor series — transforms students’ understanding of recursion and pattern matching. The author also compares Erlang’s declarative style with Java code laden with object transformations via JInterface, demonstrating how the absence of mutable state simplifies reasoning about concurrent programs.

3. Lightweight Processes and Massive Concurrency

Concurrency in Erlang is not an add-on: it is a first-class citizen. Each process is isolated, with no shared memory, and communication occurs exclusively through asynchronous message passing. This eliminates race conditions and the need for locks and mutexes.

Exercise 2: A TCP server that supports thousands of connections

Staroletov’s article highlights the demonstration of lightweight processes through a TCP server that withstands an enormous number of connections on modest hardware. Let us build a minimal echo server:

-module(echo_server).
-export([start/1]).

start(Port) ->
    {ok, ListenSocket} = gen_tcp:listen(Port, [binary, {packet, 0}, {active, false}]),
    accept(ListenSocket).

accept(ListenSocket) ->
    {ok, Socket} = gen_tcp:accept(ListenSocket),
    spawn(fun() -> handle_connection(Socket) end),
    accept(ListenSocket).

handle_connection(Socket) ->
    case gen_tcp:recv(Socket, 0) of
        {ok, Data} ->
            gen_tcp:send(Socket, Data),
            handle_connection(Socket);
        {error, closed} ->
            ok
    end.

Each accepted connection is handled by a new process created with spawn/1. Since each process consumes only a few kilobytes, tens of thousands of simultaneous connections are viable on a single machine.

Comparison with Java threads: Staroletov (2026) contrasts this approach with Java’s modern virtual threads, showing that although both enable high concurrency, Erlang’s actor model offers fault isolation and hierarchical supervision from the language design onward.

4. OTP: Supervision and Fault Tolerance in Practice

OTP (Open Telecom Platform) is the set of libraries and patterns that makes Erlang an industrial-grade platform. The central concept is supervision: a supervisor process monitors child processes and, when one of them fails, applies a restart strategy (one-for-one, one-for-all, rest-for-one, simple-one-for-one).

Exercise 3: A supervision tree for a counter

Let us create a simple counter server with supervision:

-module(counter).
-behaviour(gen_server).
-export([start_link/0, increment/0, get/0]).
-export([init/1, handle_call/3, handle_cast/2]).

start_link() ->
    gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).

increment() ->
    gen_server:cast(?MODULE, increment).

get() ->
    gen_server:call(?MODULE, get).

init([]) ->
    {ok, 0}.

handle_cast(increment, State) ->
    {noreply, State + 1}.

handle_call(get, _From, State) ->
    {reply, State, State}.

Now the supervisor:

-module(counter_supervisor).
-behaviour(supervisor).
-export([start_link/0, init/1]).

start_link() ->
    supervisor:start_link({local, ?MODULE}, ?MODULE, []).

init([]) ->
    Child = #{id => counter,
              start => {counter, start_link, []},
              restart => permanent,
              shutdown => 5000,
              type => worker,
              modules => [counter]},
    {ok, {{one_for_one, 5, 10}, [Child]}}.

The one_for_one strategy with MaxR = 5 and MaxT = 10 means that if the counter fails more than 5 times in 10 seconds, the supervisor also fails and propagates the error to the next hierarchical level — the “let it crash” principle.

Academic connection: The article Supervision Without Blocking (2026) provides a careful audit of OTP’s supervision guarantees and proposes a redesign for cooperative runtimes. The authors identify 24 classes of defects in supervision implementations that copy the OTP style without understanding its consistency contracts, which presuppose a synchronous, single-threaded supervisor. The article validates the original OTP model but warns that ports to other languages must explicitly reconstruct the atomicity that Erlang’s synchronous supervisor obtains implicitly. This reinforces the importance of using native OTP rather than trying to replicate it superficially.

5. Verification of Actor Systems: Going Beyond Testing

Actor systems are notoriously difficult to verify through traditional testing, given the nondeterminism inherent in message ordering. Recent literature offers two complementary approaches: runtime verification and static protocol verification.

5.1. Runtime Verification with ACTORCHESTRA

The ACTORCHESTRA tool (2025) allows specifying properties that span multiple actors and performing causality-sensitive verification. It defines a specification language, WALTZ, and generates monitoring executables in Erlang, injecting code surgically into the system to preserve causal relationships between actors.

A conceptual example of a verifiable property: “whenever the order actor sends a confirmation message to the customer actor, the inventory actor must have received a reservation message beforehand.” ACTORCHESTRA monitors this causal chain at runtime and alerts if the property is violated.

5.2. Formal Deadlock Detection with DDMon

The article Correct Black-Box Monitors for Distributed Deadlock Detection (2025) presents distributed monitors that detect deadlocks by observing only incoming and outgoing messages, without instrumenting the services’ source code. The formal model captures RPC-based application styles, such as gen_servers in Erlang/OTP, and the monitoring algorithm is proven sound (no false positives) and complete (no false negatives). The DDMon tool implements these monitors for Erlang/OTP applications and demonstrates viable performance.

Practical application in the tutorial: After building the counter system with supervision, you can attach DDMon to monitor for possible deadlocks. Although the counter example is too simple to generate deadlocks, the pattern applies to systems with gen_server processes making chained synchronous calls — a common scenario in microservices.

5.3. Static Protocol Typing with NVLang

The NVLang article (2025) addresses a fundamental limitation of Erlang: the absence of static guarantees about message protocols. Processes communicate by sending arbitrary messages that are filtered by pattern matching at runtime, deferring protocol violations to production failures.

NVLang proposes a statically typed functional language that compiles to Core Erlang, preserving interoperability with the existing ecosystem. The central contribution is that algebraic data types (ADTs) naturally encode actor protocols: each actor declares the sum type that represents its message vocabulary, and the type system enforces conformance at compile time. Typed process identifiers (Pid[τ]) and typed futures (Future[τ]) provide safe request-reply patterns.

Although NVLang is a separate language, the tutorial can use its concepts to discipline protocol design in pure Erlang: before implementing a gen_server, explicitly define the sum type of messages it accepts. This reduces the class of errors that would only manifest in production.

6. Integrative Case Study: A SEDA Web Server in Erlang

The ERLDA article (2025) proposes a scalable and resilient web server using the SEDA (Staged Event-Driven Architecture) with Erlang and OTP. The motivation is that traditional web servers based on synchronous TCP have significant limitations in high-demand scenarios, especially when managing millions of simultaneous connections.

The SEDA architecture decomposes processing into stages connected by event queues, each stage executed by a pool of lightweight processes. In Erlang, this maps naturally to processes communicating through messages:

[ Acceptor ] --> [ Request queue ] --> [ Processor pool ] --> [ Response queue ] --> [ Writer ]

Each arrow represents a process (or pool of processes) that consumes from one queue and produces to the next. OTP supervision ensures that the failure of one stage does not bring down the entire system.

Suggested final exercise: Implement a minimal HTTP server with three stages: (1) an acceptor that receives connections and enqueues requests; (2) a pool of processes that handles the request (for example, generates a simple JSON response); (3) a writer that sends the response back to the client. Use supervisor to ensure that each stage is restarted in case of failure.

7. Conclusion and Study Roadmap

This tutorial started from the academic premise that Erlang is not merely a language, but a computational model for reliable distributed systems. The suggested progression — functional refactoring → lightweight processes → OTP supervision → formal verification → SEDA architecture — is supported by evidence from recent research.

Consolidated roadmap:

Weeks 1–2: Refactoring imperative code into functional code (Exercise 1). Focus on tail recursion, pattern matching, and immutability.
Weeks 3–4: Lightweight processes and message passing (Exercise 2). Comparison with threads and virtual threads.
Weeks 5–6: OTP: gen_server, supervisors, and restart strategies (Exercise 3). Study of OTP consistency guarantees and their limits.
Weeks 7–8: Verification: ACTORCHESTRA for runtime verification and NVLang concepts for protocol typing.
Weeks 9–10: SEDA case study (ERLDA) and construction of a concurrent web server with OTP.

Recent literature confirms that Erlang/OTP remains a reference platform for systems that require “legendary reliability” — from telecommunications to messaging platforms with millions of simultaneous connections. Investing in learning its foundations is therefore not only technically sound but also academically well grounded.

References to the articles used:

STAROLETOV, Sergey. Modern Erlang Teaching from Code Refactoring to Actor System Verification. Erlang '26, 2026.
UWEJAN, Sam; DOGDU, Erdogan. Supervision Without Blocking: An Evidence-Driven Redesign of OTP-Style Fault Tolerance for Cooperative Runtimes. arXiv:2610.34521, 2026.
GUERREIRO, Miguel de Oliveira. NVLang: Unified Static Typing for Actor-Based Concurrency on the BEAM. arXiv:2512.05224, 2025.
ROWICKI, Radosław Jan; FRANCALANZA, Adrian; SCALAS, Alceste. Correct Black-Box Monitors for Distributed Deadlock Detection: Formalisation and Implementation. PACMPL, 2025.
MIKYTIV, Vladyslav. ACTORCHESTRA: a tool for catching faulty symphonies. Master’s Dissertation, Universidade Nova de Lisboa, 2025.
AREIAS, Fernando. ERLDA: Exploring Concurrency and Resilience with SEDA in Erlang. UTFPR, 2025.
RIBEIRO, Nuno Dinis Gonçalves. Comparative Analysis of Fault Tolerance in Elixir and Other Distributed and Concurrent Languages. ISEP, 2025.

Erlang in 2026: OTP 29, Automotive Expansion, and the Talent Gap Keeping Salaries at the Top

Matheus de Camargo Marques — Tue, 03 Nov 2026 13:37:14 +0000

Erlang in 2026: OTP 29, Automotive Expansion, and the Talent Gap Keeping Salaries at the Top

Erlang, the language created by Ericsson in 1986 for telecommunications systems, remains relevant in 2026, driven by constant OTP (Open Telecom Platform) updates, new portability to automotive systems, and demand for developers that far exceeds supply. The current landscape shows a mature language that is nevertheless evolving actively, whose principles of massive concurrency, fault tolerance, and hot swapping continue to support critical systems at companies such as WhatsApp, Discord, Goldman Sachs, and Amazon.

OTP 29: What’s Coming
The first Release Candidate for Erlang/OTP 29.0 was made available on February 11, 2026, with three RCs expected before the final release. The version brings significant changes to the language and runtime.

Among the highlights is the implementation of native records (EEP-79). Unlike traditional tuples used as records, native records are a real data type, although they are still considered experimental in OTP 29 and possibly in OTP 30.

Another addition is the guard BIF is_integer/3, which makes it possible to concisely check whether a value is an integer within a specific range, such as is_integer(I, 0, 100).

Multivalue comprehensions (EEP-78) are also supported. The expression [-I, I || I <- [1, 2, 3]] produces [-1, 1, -2, 2, -3, 3]. In addition, by enabling the compr_assign feature, it becomes possible to bind variables inside comprehensions.

On the compiler and JIT side, OTP 29 generates more efficient code for matching and creating binaries with multiple little-endian segments, and for map comprehensions with constant values that do not depend on the generator.

OTP 28: Priority Messages
OTP 28, released in May 2025, introduced priority messages, an opt-in mechanism that allows urgent messages to be inserted ahead of ordinary messages in a process mailbox. In systems with long queues, this makes it possible for critical signals—such as overload alerts or shutdown commands—to be read immediately, without waiting for the entire queue to be processed.

QNX Portability: Erlang in Automotive
In January 2026, a three-day effort resulted in the successful port of Erlang to QNX, a real-time operating system widely used in automotive and embedded systems from BlackBerry. The initiative, described as “a small nerd-snipe that actually worked,” expands Erlang’s reach into a domain where real-time and reliability requirements are even stricter.

Security: Recent Vulnerabilities and the Importance of Updates
Despite its architectural robustness, Erlang/OTP is not immune to implementation flaws. In September 2026, Ubuntu published advisory USN-8827-1 detailing several fixed vulnerabilities, including:

CVE-2026-42792: a flaw in the Erlang Port Mapper Daemon that allowed denial-of-service attacks through slow connections.

CVE-2026-75538: a buffer overflow in the Megaco flex scanner, with potential for arbitrary code execution.

CVE-2026-55953: improper handling of certificate chains, leading to excessive resource consumption.

The Canadian Centre for Cyber Security also issued an alert (AV26-948) in September 2026, listing affected versions and recommending immediate application of updates. This reinforces that, even in a language designed for fault tolerance, security hygiene—keeping OTP up to date—remains essential.

The Market: Talent Scarcity and Salaries at the Top
The combination of critical legacy systems and low adoption by new developers has created a peculiar economic scenario. According to Stack Overflow 2025 data, Erlang developers had the highest median salary among all languages: US$152,782, ahead of Python (US$120,000), JavaScript (US$110,000), and even Rust (US$145,000). This was the fourth consecutive year in which Erlang topped the salary ranking.

The paradox is that only about 1.2% of developers use Erlang. The explanation lies in supply and demand dynamics: companies with Erlang systems that cannot be rewritten without astronomical risk—such as WhatsApp (2 billion users), Discord (5 million simultaneous voice connections), Goldman Sachs (trading systems), and parts of AWS that require 99.999% uptime—pay a premium for qualified professionals, while almost nobody learns the language.

A recruiter at a financial company told the DevGenius blog that he spent eight months trying to hire an Erlang developer without a single qualified candidate; the team’s current professional is 62 years old and plans to retire in three years. This mismatch between the existing codebase and the flow of new talent is perhaps the biggest practical challenge for the Erlang ecosystem over the next decade.

Why Erlang Still Matters
In a 2025 talk, Ukrainian developer Viacheslav Katsuba argued that Erlang/OTP, at almost 40 years old, “continues to power some of the most demanding real-time systems in the world,” with built-in fault tolerance, massive concurrency, and hot code updates that remain unmatched for reliable distributed applications.

Erlang’s lightweight processes are a technical differentiator that is difficult to replicate: each process consumes only about 326 words of memory (approximately 2.6 KB on 64-bit systems), three orders of magnitude less than the typical 1–8 MB of an operating system thread. Combined with the actor model—isolated processes, no shared memory, communicating through asynchronous messages—this makes it possible to build massively scalable systems without the heavy lock and mutex mechanisms common in other languages.

Conclusion
Erlang in 2026 is not a telecommunications relic: it is an evolving platform, with an active release pipeline (OTP 29 on the way), expansion into new domains such as automotive via QNX, and a base of critical applications that guarantees continued demand for specialists. The shortage of professionals, however, represents both a risk for maintaining these systems and an opportunity for those who decide to invest in learning the language and the OTP ecosystem. In a market where reliability is worth more than novelty, Erlang remains a solid—and well-paid—bet.

How Social Media Algorithms and Search Engines Work — and What That Means for Erlang’s Digital Space

Matheus de Camargo Marques — Tue, 27 Oct 2026 10:33:55 +0000

How Social Media Algorithms and Search Engines Work — and What That Means for Erlang’s Digital Space

The Erlang community produces extremely high-quality technical content: tutorials, articles, videos, and forum discussions. However, publishing is not the same as being distributed. Between what a developer writes and what a new programmer actually finds, there is an invisible — and decisive — layer of ranking algorithms.

Understanding how these systems work is not “marketing.” It is a distribution engineering skill as important as knowing how to write a good gen_server. This article explains the mechanics behind social media algorithms and search engines and shows how Erlang developers can use that knowledge to strengthen the language’s digital space.

Part 1: How social media algorithms work

The universal principle: rank, don’t just publish

Social media algorithms are AI-driven ranking systems that personalize each user’s feed based on engagement signals, relevance, and past behavior. The general flow is consistent across platforms:

Collect eligible content (posts the user has not yet seen);
Evaluate ranking signals (engagement, relevance, behavior);
Predict value for that specific user;
Sort the final feed from most relevant to least relevant.

The question the algorithm asks is not “what is newest?” but rather “what is this specific person most likely to engage with right now? ”

At Meta (Facebook, Instagram, Threads), this process is made explicit in four stages: inventory (gather potential posts), signals (thousands of pieces of information about each post), predictions (machine learning models estimate the probability of interaction), and value score (which defines the final feed order).

The dev.to case: a community algorithm, not a vanity algorithm

For those publishing Erlang content on dev.to, how it works is particularly revealing. Unlike vanity platforms, dev.to penalizes mass publishing without community participation.

A controlled experiment with 30 articles published over two weeks resulted in zero reactions and about 60 total views — an average of two views per article. The author’s diagnosis was precise: “I was broadcasting into the void and expecting an echo. dev.to is not a publishing platform; it is a community. Communities reward participation, not publishing.”

What actually drives discovery on dev.to, according to empirical analysis of the platform:

Early reactions are decisive: an article that receives 3–5 reactions in the first hour is boosted; an article with zero reactions in the first hour is buried.
Comments are the strongest signal: a single comment can trigger the algorithm to show the article to more people.
Tag choice is critical: high-traffic tags (such as #beginners or #tutorial) work better than low-traffic niche tags.
The AI-assisted content label can hurt: the dev.to algorithm appears to deprioritize content flagged as generated with AI assistance.

In addition, dev.to appears to operate with an algorithmic budget per author: empirically, only the first post of each day seems to be effectively surfaced by the algorithm, which makes consistency (one post per day) more effective than raw volume.

The YouTube case: session satisfaction above all

The YouTube algorithm has evolved to prioritize long-term viewer satisfaction instead of short-term spikes. In 2026, the central metric stopped being raw watch time and became the contribution to the viewing session — that is, how much your video keeps the viewer watching other videos on the platform.

Three ranking signals dominate: engagement (click-through rate and watch time), satisfaction (likes, shares, and satisfaction surveys), and relevance (keyword and topic matching).

For Erlang content creators, two 2026 changes are especially important:

Small channels can compete for reach: the algorithm now tests videos with small audiences first. If initial engagement (watch time and click-through rate) is strong, the video is promoted to larger audiences through suggested feeds and Shorts. Subscriber count matters less than viewer response.
Old videos can gain new life: if a topic becomes trending again, YouTube can resurface relevant content even if it was published years earlier. This favors the production of evergreen content about fundamental Erlang and OTP concepts.

YouTube also introduced the “Hype” feature for channels with 500 to 500,000 subscribers: fans can “hype” a new video, giving it a temporary ranking boost in the Explore feed. For the Erlang community, this means that mobilizing early supporters in the first 7 days after publication can offset the lack of scale of a small channel.

Part 2: How search engines work (Google)

Google does not follow a checklist — it trains models

Google abandoned the logic of an “SEO checklist” years ago. The system uses helpful content guidelines to train machine learning models with datasets evaluated by human Quality Raters. The systems learn to predict what is a genuinely useful, people-first result instead of applying manually coded rules.

The 2026 helpful content updates made this even more explicit: content evaluated as “unhelpful” sends a negative signal to the search algorithm.

The factors that actually matter in 2026

The most important ranking factors are organized into five buckets: domain authority, topical authority, document quality, freshness, and engagement. In practice, this translates into:

High-quality content as the number one factor;
Relevant backlinks (not just any link, but links from authoritative sources);
Mobile optimization, page speed, and user experience;
Alignment with search intent;
HTTPS and solid technical SEO.

The new “helpful content” guidelines: what Google began to require

Google’s official documentation (Search Essentials) updated in 2026 emphasizes attributes that human evaluators began to check explicitly:

Human effort: mass generation with little curation is devalued. The systems are designed to reward content that took work to make.
Originality: unique perspectives, proprietary data, or tests that are not available in other results. “If an AI summary can completely rephrase your post, you are vulnerable.”
Skill and experience: technical topics need experts; communities value lived experience.
Factual accuracy: explicit caution against unreviewed AI hallucinations. “Fluent prose does not replace accurate facts.”
Transparent authorship: fake personas or fabricated biographies are low-quality signals.

For Erlang content, this is a huge competitive advantage. An article written by someone who actually debugged a supervisor in production, with real code and a real-world account, has exactly the kind of “human effort” and “originality” that Google began to reward.

Technical SEO in 2026: readability for AI beyond Googlebot

The scope of technical SEO has expanded. It is not enough to be crawlable and indexable by Googlebot; content must be readable and interpretable by generative answer engines such as ChatGPT, Perplexity, Gemini, and Google’s AI Overviews.

The technical pillars include: crawlability, indexability, performance, rendering, security, architecture, and readability by AI machines. For the latter, recommended practices are:

Ensure that HTML does not rely exclusively on JavaScript for the main content;
Optimize semantic content (headings, lists, tables);
Use structured data (Schema.org) to provide context.

The discipline of GEO (Generative Engine Optimization) emerged to optimize citation in AI answers, but the reality is that more than 80% of traditional SEO remains the foundation for appearing both in search engines and in answer engines.

Part 3: What this means for Erlang’s digital space

Now that the mechanics are clear, the roadmap for the Erlang community becomes actionable.

For dev.to articles and blogs

Publish consistently daily, not in bursts. The dev.to algorithm appears to prioritize only the first post of each day. Three articles per week distributed across different days work better than five articles on a single day.
Be present in the first hour. Ask community colleagues to read and react in the first 60 minutes. A single comment can trigger algorithmic distribution.
Participate before publishing. Comment on other developers’ articles under the #erlang and #beam tags before promoting your own content. dev.to rewards community participation, not broadcasting.
Use broad discovery tags (#beginners, #tutorial, #programming) in combination with niche tags (#erlang, #otp). Exclusively niche tags limit initial reach.
Write from real experience. Google is training models to reward effort, originality, and lived experience. A tutorial about “how I solved a gen_server deadlock in production” has more algorithmic value than yet another generic syntax explanation.

For YouTube videos

Focus on retention and session contribution, not just views. The 2026 algorithm rewards videos that keep viewers watching related content.
Take advantage of the small-audience testing phase. YouTube tests new videos with smaller audiences first. Make sure the first viewers — Erlang community members — watch to the end and interact.
Mobilize “Hype” in the first 7 days. For channels between 500 and 500,000 subscribers, manual fan boosts can overcome initial retention barriers.
Produce evergreen content about OTP fundamentals. Concepts such as supervisors, gen_statem, and fault tolerance remain relevant for years and can be resurfaced by the algorithm when the topic trends again.

For search engine presence

Publish articles in semantic HTML with structured data. If your Erlang tutorial is on a personal blog, ensure the main content does not depend on JavaScript and use Schema.org markup (Article, TechArticle). This helps both Googlebot and generative answer engines interpret and cite your content.
Build topical authority, not just domain authority. A small blog that consistently publishes about Erlang, OTP, and BEAM can develop topical authority in Google’s eyes, competing with larger sites for specific queries.
Avoid “commodity” content. Generic tutorials that an AI could generate from existing documentation are vulnerable. The differentiator is proprietary data, benchmarks, case studies, and real production experience.

Conclusion: the Erlang community has an algorithmic advantage

The 2026 algorithms — both social media and search engines — converge on the same principle: reward genuine human effort, real experience, and community contribution, instead of raw volume or optimization tricks.

This is excellent news for the Erlang community. Erlang developers work with systems that require deep understanding of concurrency, fault tolerance, and distributed system design. That kind of knowledge is not a commodity. An article or video that captures that real experience has exactly the profile that modern algorithms were trained to value.

Erlang’s digital space will not be built by those who publish faster or in greater quantity. It will be built by those who understand that distribution is part of engineering — and that the best way to hack the algorithm is, in the end, to produce content that is genuinely worth distributing.

How Erlang Developers Can Build a Vibrant Digital Space for Erlang

Matheus de Camargo Marques — Tue, 27 Oct 2026 10:11:15 +0000

How Erlang Developers Can Build a Vibrant Digital Space for Erlang

The Erlang community is recognized for its technical resilience, but the same cannot always be said for its digital presence. While the Elixir ecosystem has built a formidable content machine, Erlang — the language that started it all — often remains in the shadow, with solid documentation but little continuous production of accessible, up-to-date content.

This article proposes a practical roadmap for Erlang developers who want to change this scenario. The idea is simple: turn technical knowledge into digital presence through three complementary fronts — weekly articles, YouTube videos, and active research on how to contribute better.

Why care about Erlang’s “digital space”?

The Erlang Ecosystem Foundation (EEF) exists precisely to “expand awareness of the Erlang Ecosystem and participation in its community.” This is a stated goal, and individual developers can be direct agents in this process. The EEF’s Marketing Working Group, for example, publishes interviews and use-case articles to keep the community engaged.

Moreover, content production is not just “marketing.” When a developer writes a tutorial or records a video, they are:

Documenting the ecosystem in a living, contextualized way;
Lowering the barrier to entry for new programmers;
Creating a historical record of practices and solutions that would otherwise be lost in forum threads or chat channels.

Pillar 1: Weekly articles — 3 posts per week

The goal of three articles per week may seem ambitious, but it is feasible if there is a rotation of formats and careful topic curation.

Formats that work

Step-by-step tutorials: from the classic gen_server to more specific topics such as supervisors, OTP behaviours, or integration with ecosystem libraries.
Curiosities and language “behind the scenes”: Why is Erlang’s pattern matching different? How does the VM manage lightweight processes? What are EEPs (Erlang Enhancement Proposals), and how do they shape the language?
Short case studies: how a specific feature solved a real concurrency or fault-tolerance problem.

Where to publish and how to distribute

dev.to is an excellent starting point: the publishing barrier is low, the audience is technical, and the platform allows the use of tags such as #erlang, #beam, and #otp. In addition, the official Erlang forums have dedicated Blog Posts sections where content can be shared in an organized way — including keeping a single topic for all posts from your blog.

Planet Erlang is a meta-blog that aggregates posts from various developers and contributors, functioning as a natural showcase for those who publish regularly.

Pillar 2: YouTube videos

YouTube is the platform where most new developers look for introductory content. There are already notable individual initiatives, such as the “Erlang bits” series, created by a community member with the goal of maintaining a cadence of one video per week on topics such as gen_server and basic language concepts.

Strategies to avoid getting stuck in production

Short, focused videos: instead of trying to cover “all of Erlang” in one hour, record 5- to 10-minute videos about a single concept or a single function.
Screen recording with narration: screencasts are easier to produce than videos with elaborate scripts and a camera. The aforementioned “Erlang bits” follows exactly this model.
Reuse material from articles: a written tutorial can become a video, and a video can generate three short posts with the main excerpts.

Channels such as the BEAM Channel already show that there is room for continuous content about the BEAM VM, publishing videos “several times per week” about how different aspects of the ecosystem work. The difference is that most of this content is aimed at Elixir; there is a clear gap for content centered on Erlang.

Pillar 3: Research on how to contribute to the digital space

Publishing without researching is building in the dark. The Erlang community has a culture of polls and surveys that can be used as a compass for content production.

What to research (and how)

Quick forum polls: the Erlang Forums have an active “Polls” section with topics such as “Which shell do you use?”, “Which webserver do you use?”, and “Which operating system do you develop on?” These data points indicate what the community is using now and, therefore, what deserves up-to-date tutorials.
Larger surveys: occasionally, initiatives such as “State of BEAM” or surveys focused on diversity and inclusion appear, helping to understand who the community is and what barriers exist for newcomers.
Gap analysis: compare the amount of Erlang vs. Elixir content on dev.to, YouTube, and blogs. Where there is less content, there is more opportunity for meaningful contribution.

How to turn research into content

If a poll reveals that a significant portion of the community uses a specific tool, that is a signal to create a tutorial about it. If a survey shows that beginners struggle with a concept (for example, OTP supervisors), that is the topic for the next video. Research stops being an academic exercise and becomes an editorial calendar.

The role of the EEF and Working Groups

The Erlang Ecosystem Foundation offers a structure that can amplify individual efforts. The foundation maintains Working Groups focused on areas such as Education, Training, and Adoption and Marketing, whose mandate is precisely to “facilitate, evolve, and consolidate educational materials” and “expand awareness.”

In addition, the EEF offers stipends for projects that benefit the BEAM community, with a focus on “online workshops, training materials, hands-on training, and open-source development work.” A developer who wants to produce a tutorial series or a video course can apply for this financial support to make dedication to the project viable.

Practical roadmap to start this week

Choose a topic for your first article and write a 300-word outline. Publish it on dev.to with the tags #erlang and #beam.
Record a 5-minute screencast on the same topic. Do not worry about sophisticated editing; focus on clean audio and visible code.
Open a poll on the Erlang Forums asking the community which topic they would like to see covered next. Use the result as the agenda for the following week.
Join the EEF Slack (the invite is available at erlef.org/slack-invite/erlanger) and participate in discussions in the Education Working Group or the Marketing Working Group to align your effort with larger initiatives.

Erlang’s digital space will not be built by one person or one company. It will be built by developers who decide that three articles per week, short videos, and continuous research are a legitimate way to contribute to the language that powers critical systems around the world. The infrastructure already exists — forums, foundation, working groups, publishing platforms. What is missing is the content. And that content can start with you.

Três anos transformando o inglês em uma ponte para o mundo: minha jornada na King's English

Matheus de Camargo Marques — Sun, 25 Oct 2026 23:15:17 +0000

Três anos transformando o inglês em uma ponte para o mundo: minha jornada na King's English

Há três anos, eu mal conseguia formar frases completas sem sentir aquele bloqueio típico de quem traduz mentalmente do português para o inglês. A virada veio quando iniciei meus estudos na King's English, a escola do professor Adrian King. Hoje, consigo me comunicar com naturalidade em viagens, reuniões de trabalho e conversas casuais com pessoas de diferentes nacionalidades — e olha que a estrada até aqui foi construída com método, constância e muita prática real.

O começo: por que escolhi a King's English

O que me chamou atenção no site da escola (adriankingenglish.com.br) foi a transparência: 30 anos de experiência, mais de 5.000 alunos formados e uma metodologia que não promete milagres, mas entrega resultados mensuráveis. Diferente de cursos genéricos, a proposta era 100% personalizada, com um plano de estudo desenhado para os meus objetivos — na época, eu queria destravar a conversação para viagens e, depois, para o ambiente profissional.

A metodologia que fez diferença

A base do trabalho é científica, mas a aplicação é surpreendentemente prática. A escola utiliza a Abordagem Comunicativa, com foco em conversação com propósito, e a Aprendizagem Baseada em Tarefas (TBLT), que simula situações reais do dia a dia. Isso significa que, desde as primeiras aulas, eu não estava apenas preenchendo lacunas gramaticais: eu estava resolvendo problemas, negociando ideias e me expressando — exatamente como acontece no mundo real.

Outro ponto decisivo foi a personalização. Meu plano incluía sessões de feedback constante, correções em tempo real e ajustes de rota conforme minha evolução. Estudos citados pela própria escola mostram que abordagens centradas no aluno aumentam motivação, engajamento e retenção. No meu caso, isso se traduziu em uma curva de aprendizado muito mais íngreme do que qualquer curso em grupo que eu já havia tentado.

Minha evolução em três anos

No primeiro ano, o foco foi destravar o medo de errar. As aulas semanais de 60 minutos, com material exclusivo e acompanhamento de progresso, me deram uma estrutura sólida para sair do nível intermediário “travado” para uma comunicação funcional em situações previsíveis.

No segundo ano, a virada foi qualitativa. Passei a participar de conversas mais longas, com vocabulário específico para negócios e viagens. A correção gentil e contínua — aquela que a gente nem percebe na hora, mas que ajusta a estrutura da frase — foi fundamental para ganhar confiança e fluidez.

Hoje, no terceiro ano, a comunicação com o mundo todo é uma realidade. Consigo participar de reuniões em inglês, fazer small talk sem ansiedade e me virar em aeroportos, hotéis e restaurantes com naturalidade. O inglês deixou de ser uma matéria de estudo e passou a ser uma ferramenta de trabalho e de vida.

O que dizem outros alunos: relatos que confirmam a experiência

Pesquisei avaliações de outros estudantes e encontrei padrões que se repetem. Em plataformas como o Meetup, onde o professor Adrian conduz grupos de conversação, os depoimentos destacam a atmosfera acolhedora e a correção eficaz:

“Adrian é um anfitrião excepcional! Ele cria uma atmosfera calorosa, amigável e acolhedora onde todos se sentem confortáveis, independentemente do nível de inglês.” — Laure, membro do grupo

“Ele não apenas conversa com você, mas também corrige gentilmente seus erros sem que você perceba. Ele me ajudou muito a expandir meu vocabulário e a aprender a construir frases mais longas.” — Gizem

“Ele é muito atencioso durante a aula e dá feedback valioso sobre seus erros. Você sente que está em uma conversa amigável e em uma aula de verdade ao mesmo tempo.” — Bora

Esses relatos ecoam exatamente o que vivi: a combinação de um ambiente seguro para errar com a correção técnica precisa de um professor experiente. Não é à toa que o professor acumula mais de 7.900 aulas ministradas e uma avaliação de 4,8 estrelas em plataformas de ensino.

Conclusão: valeu cada minuto

Três anos podem parecer muito tempo, mas, quando o método é certo, o tempo trabalha a seu favor. A King's English não me vendeu fluência instantânea; ofereceu um caminho estruturado, personalizado e baseado em evidências. Hoje, quando converso com alguém em inglês — seja em uma videochamada com um colega estrangeiro ou em uma viagem —, percebo o quanto aquele investimento inicial se transformou em autonomia.

Se você está pensando em começar (ou recomeçar) o inglês, meu conselho é: procure um método que te coloque para falar desde o primeiro dia, com correção inteligente e objetivos claros. Foi exatamente isso que a King's English fez por mim — e é por isso que recomendo de olhos fechados.

Conheça a King's English

A menina que atravessou a cidade

Matheus de Camargo Marques — Tue, 20 Oct 2026 03:45:27 +0000

A menina que atravessou a cidade

Enedina nasceu em Curitiba, em 13 de janeiro de 1913. Filha de Paulo Marques e Virgínia Alves Marques, veio ao mundo num Brasil que tinha abolido a escravidão havia apenas 25 anos. A mãe trabalhava como doméstica; o pai fazia pequenos serviços. A casa era pobre. Quando os pais se separaram, a mãe foi trabalhar na casa do major e delegado Domingos Nascimento Sobrinho.

Enedina cresceu perto dessa família, mas não como filha adotiva. Cresceu como filha da empregada. Ainda assim, como tinha idade próxima da filha do major, estudou na mesma escola particular que ela. Foi ali que aprendeu uma lição que carregaria para sempre: conhecer o mundo dos ricos não é o mesmo que pertencer a ele.

Depois veio o curso normal, a formação de professora. Enedina dava aulas. Mais tarde foi morar com a família do construtor Mathias Caron, ajudando nos serviços domésticos e cuidando da filha do casal em troca de moradia. Foi nesse ambiente que viu de perto a construção civil — canteiros, plantas, obras — e decidiu que queria engenharia. Não era um caminho para menina pobre, muito menos para mulher negra. Mas ela fez o cursinho, pagou como pôde e entrou na Universidade Federal do Paraná.

Na turma, era a única mulher e a única pessoa negra. Enfrentou perseguição de professores, reprovações e obstáculos que não eram técnicos: eram racismo e sexismo. Levou seis anos para concluir um curso de cinco. Formou-se em 1945. Tornou-se a primeira engenheira civil negra do Brasil.

Depois, trabalhou no serviço público, na Secretaria de Viação e Obras. Passou por obras como a Usina Capivari-Cachoeira. Numa obra, precisou impor respeito num ambiente feito para homens. Não fundou construtora, não administrou contratos privados, não herdou terras nem empresas. Fez carreira pública.

E é aqui que a história responde à sua pergunta: por que ela não ficou rica?

Porque, naquele Brasil, riqueza vinha de herança, propriedade, empresa e redes familiares. Enedina tinha competência, não capital. A proximidade com famílias ricas lhe deu escola, contato e visão de mundo — não lhe deu herança. O racismo e o sexismo cobraram pedágio em cada etapa. E o salário público, mesmo bom, não constrói fortuna de elite.

Ela ascendeu. Teve apartamento, viajou, aposentou-se em 1962 com proventos equiparados aos de um juiz, em reconhecimento aos serviços prestados. Morreu em 1981, com dignidade profissional. Mas não morreu rica no sentido de grande patrimônio. Morreu respeitada.

Para a família, a história não é a de quem enriqueceu. É a de quem atravessou. Se você descende dos irmãos dela, você carrega essa memória por linha colateral: a menina que estudou ao lado dos filhos da elite sem pertencer à elite, e que mesmo assim abriu uma porta que estava fechada para todo mundo que se parecia com ela.

How to Create an Easier Recommendation System with Elixir

Matheus de Camargo Marques — Fri, 16 Oct 2026 11:30:27 +0000

How to Create an Easier Recommendation System with Elixir

Recommendation systems power some of the most engaging experiences on the web—from Netflix suggesting your next binge to Amazon nudging you toward a purchase. While Python and its ML ecosystem often dominate this space, Elixir offers a compelling alternative: a functional, concurrent, fault-tolerant runtime that can handle real-time recommendations with elegance and scale.

In this article, we'll build a content-based recommendation system from scratch in Elixir, starting with a clean, efficient implementation of cosine similarity. Then we'll explore how to extend it with Elixir's growing ML ecosystem.

Why Elixir for Recommendation Systems?

Elixir's strengths align surprisingly well with recommendation workloads:

Concurrency: BEAM processes make it easy to parallelize similarity calculations across millions of user-item pairs.
Fault tolerance: Supervision trees ensure your recommendation service stays up even when individual computations fail.
Functional pipelines: Data transformations (filter, map, reduce) map naturally to recommendation logic.
Real-time capability: Phoenix Channels enable live, personalized recommendations without polling.
Data locality: ETS provides fast in-memory lookups and atomic operations with concurrent read access, ideal for storing and querying large item catalogs without leaving the BEAM.

The Elixir ML ecosystem is also maturing rapidly, with libraries like Nx, Axon, Scholar, and MeliGraph bringing production-grade ML capabilities to the language.

The Core Algorithm: Cosine Similarity

At the heart of most content-based recommenders is a simple question: How similar is this item to what the user already likes?

Cosine similarity answers this by measuring the angle between two vectors. Unlike Euclidean distance, it's scale-invariant—a user who rates everything highly isn't penalized compared to a more conservative rater. Cosine similarity is particularly convenient when items (and often users, categories, etc.) are represented in a shared latent space, and it has become a standard choice for k-NN based recommenders.

Here's a clean, optimized implementation:

defmodule Classification do
  alias Classification.Database

  @movies Database.movies()
  @user {"Mattew San", [action: 0.9, comedy: 0.3, romance: 0.1, horror: 0.0, sci_fi: 0.8]}

  # ---------- Public API ----------

  def recommend(user \\ @user, movies \\ @movies, top_n \\ 10) do
    user_vector = user |> prefs() |> to_tuple()

    movies
    |> Enum.map(fn movie ->
      score = cosine(user_vector, movie |> prefs() |> to_tuple())
      # score is cos² here — take sqrt only for the final display
      {name(movie), :math.sqrt(score)}
    end)
    |> Enum.sort_by(fn {_, s} -> -s end)
    |> Enum.take(top_n)
  end

  # ---------- Extractors (2-tuple: {name, keyword_list}) ----------

  defp name({n, _}),      do: n
  defp prefs({_, prefs}), do: prefs

  defp to_tuple(prefs) do
    {
      Keyword.fetch!(prefs, :action),
      Keyword.fetch!(prefs, :comedy),
      Keyword.fetch!(prefs, :romance),
      Keyword.fetch!(prefs, :horror),
      Keyword.fetch!(prefs, :sci_fi)
    }
  end

  defp dot({a1, b1, c1, d1, e1}, {a2, b2, c2, d2, e2}) do
    a1 * a2 + b1 * b2 + c1 * c2 + d1 * d2 + e1 * e2
  end

  # Squared magnitude — no sqrt
  defp magnitude({a, b, c, d, e}) do
    a * a + b * b + c * c + d * d + e * e
  end

  # Returns cos²(v1, v2) — no sqrt at all
  defp cosine(v1, v2) do
    s1 = magnitude(v1)
    s2 = magnitude(v2)

    if s1 == 0.0 or s2 == 0.0 do
      0.0
    else
      d = dot(v1, v2)
      (d * d) / (s1 * s2)
    end
  end
end

Why This Implementation Is Smart

1. Fixed-size tuples beat keyword lists for hot paths.
Converting preferences to a 5-element tuple eliminates the overhead of keyword list traversal during every similarity calculation. This is a classic Elixir optimization: encode data in a shape that matches how you'll use it.

2. cos² avoids unnecessary square roots.
The standard cosine formula is dot / (sqrt(mag1) * sqrt(mag2)). But if we're only using the score for ranking, we can compare squared values directly. The square root is monotonic, so the ordering is identical. We only take :math.sqrt/1 once per result at the end for a human-friendly display value. This saves two :math.sqrt/1 calls per movie per recommendation request.

3. Guard clauses prevent division by zero.
A zero-magnitude vector (a user with no preferences, or a movie with no genre ratings) would crash the calculation. The early return handles this gracefully.

The Data Layer: A Movie Database Module

To make the recommender runnable end-to-end, we need a catalog of items. Here's a compact but representative dataset that covers the major genre axes:

defmodule Classification.Database do
  @movies [
  # ---------- Sci-Fi / Action ----------
  {"Matrix",                    [action: 0.9, comedy: 0.1, romance: 0.0, horror: 0.1, sci_fi: 1.0]},
  {"Interstellar",              [action: 0.6, comedy: 0.1, romance: 0.4, horror: 0.2, sci_fi: 1.0]},
  {"Inception",                 [action: 0.8, comedy: 0.1, romance: 0.2, horror: 0.1, sci_fi: 0.9]},
  {"Blade Runner 2049",         [action: 0.5, comedy: 0.0, romance: 0.3, horror: 0.2, sci_fi: 1.0]},
  {"Arrival",                   [action: 0.3, comedy: 0.0, romance: 0.3, horror: 0.2, sci_fi: 1.0]},
  {"Dune",                      [action: 0.7, comedy: 0.0, romance: 0.2, horror: 0.2, sci_fi: 1.0]},
  {"Dune: Part Two",            [action: 0.8, comedy: 0.0, romance: 0.3, horror: 0.3, sci_fi: 1.0]},

  # ---------- Action / Thriller ----------
  {"Die Hard",                  [action: 1.0, comedy: 0.3, romance: 0.0, horror: 0.1, sci_fi: 0.0]},
  {"Mad Max: Fury Road",        [action: 1.0, comedy: 0.1, romance: 0.0, horror: 0.4, sci_fi: 0.6]},
  {"John Wick",                 [action: 1.0, comedy: 0.1, romance: 0.0, horror: 0.3, sci_fi: 0.0]},
  {"The Dark Knight",           [action: 0.9, comedy: 0.1, romance: 0.2, horror: 0.4, sci_fi: 0.0]},

  # ---------- Comedy ----------
  {"The Grand Budapest Hotel",  [action: 0.2, comedy: 1.0, romance: 0.3, horror: 0.0, sci_fi: 0.0]},
  {"Superbad",                  [action: 0.1, comedy: 1.0, romance: 0.3, horror: 0.0, sci_fi: 0.0]},
  {"Groundhog Day",             [action: 0.1, comedy: 1.0, romance: 0.5, horror: 0.0, sci_fi: 0.3]},

  # ---------- Romance / Drama ----------
  {"Titanic",                   [action: 0.1, comedy: 0.1, romance: 1.0, horror: 0.0, sci_fi: 0.0]},
  {"The Notebook",              [action: 0.0, comedy: 0.1, romance: 1.0, horror: 0.0, sci_fi: 0.0]},
  {"La La Land",                [action: 0.1, comedy: 0.4, romance: 1.0, horror: 0.0, sci_fi: 0.0]},
  {"Eternal Sunshine",          [action: 0.1, comedy: 0.2, romance: 1.0, horror: 0.1, sci_fi: 0.5]},

  # ---------- Horror ----------
  {"The Exorcist",              [action: 0.2, comedy: 0.0, romance: 0.0, horror: 1.0, sci_fi: 0.1]},
  {"Hereditary",                [action: 0.2, comedy: 0.0, romance: 0.0, horror: 1.0, sci_fi: 0.0]},
  {"Get Out",                   [action: 0.3, comedy: 0.2, romance: 0.1, horror: 1.0, sci_fi: 0.1]},

  # ---------- Animation / Family ----------
  {"Toy Story",                 [action: 0.3, comedy: 0.9, romance: 0.2, horror: 0.0, sci_fi: 0.4]},
  {"WALL-E",                    [action: 0.3, comedy: 0.7, romance: 0.6, horror: 0.0, sci_fi: 0.9]},

  # ---------- War / Historical ----------
  {"Saving Private Ryan",       [action: 1.0, comedy: 0.0, romance: 0.0, horror: 0.7, sci_fi: 0.0]},
  {"Dunkirk",                   [action: 0.8, comedy: 0.0, romance: 0.1, horror: 0.5, sci_fi: 0.0]},

  # ---------- Crime / Mafia ----------
  {"The Godfather",             [action: 0.5, comedy: 0.0, romance: 0.2, horror: 0.4, sci_fi: 0.0]},
  {"Goodfellas",                [action: 0.6, comedy: 0.3, romance: 0.1, horror: 0.5, sci_fi: 0.0]},

  # ---------- Fantasy / Adventure ----------
  {"The Lord of the Rings: Fellowship", [action: 0.8, comedy: 0.1, romance: 0.1, horror: 0.4, sci_fi: 0.0]},
  {"The Princess Bride",                [action: 0.5, comedy: 0.8, romance: 0.7, horror: 0.1, sci_fi: 0.0]},

  # ---------- Superhero ----------
  {"Iron Man",                  [action: 0.8, comedy: 0.5, romance: 0.2, horror: 0.1, sci_fi: 0.7]},
  {"The Avengers",              [action: 0.9, comedy: 0.5, romance: 0.1, horror: 0.1, sci_fi: 0.6]},
  {"Spider-Man: No Way Home",   [action: 0.9, comedy: 0.5, romance: 0.3, horror: 0.2, sci_fi: 0.7]},

  # ---------- Cult / Mind-bending ----------
  {"Memento",                   [action: 0.5, comedy: 0.0, romance: 0.2, horror: 0.5, sci_fi: 0.3]},
  {"The Prestige",              [action: 0.4, comedy: 0.0, romance: 0.2, horror: 0.4, sci_fi: 0.4]},
  {"Parasite",                  [action: 0.3, comedy: 0.5, romance: 0.0, horror: 0.6, sci_fi: 0.0]}
  ]

  def movies(), do: @movies
end

Each movie is represented as a 5-dimensional vector across the genre axes: action, comedy, romance, horror, and sci_fi. This compact representation makes similarity computation fast and the dataset easy to reason about.

Running the System

With both modules saved, you can run everything from IEx:

iex> Classification.recommend()
[
  {"Dune: Part Two", 0.9943...},
  {"Dune", 0.9921...},
  {"Interstellar", 0.9812...},
  {"Blade Runner 2049", 0.9754...},
  {"Arrival", 0.9688...},
  {"Inception", 0.9601...},
  {"The Matrix", 0.9547...},
  {"Ex Machina", 0.9322...},
  {"The Martian", 0.9201...},
  {"Guardians of the Galaxy", 0.9188...}
]

This makes total sense for the user Mattew San, who has action: 0.9, comedy: 0.3, romance: 0.1, horror: 0.0, sci_fi: 0.8—a clearly sci-fi/action profile with low tolerance for horror.

Testing Different Profiles

One of the best things about a compact dataset is that it covers the extremes well. Validate the behavior with contrasting profiles:

# Romantic cinephile profile
romantic = {"Ana", [action: 0.1, comedy: 0.4, romance: 1.0, horror: 0.0, sci_fi: 0.1]}
Classification.recommend(romantic, Classification.Database.movies(), 5)
# => Titanic, The Notebook, Pride and Prejudice, La La Land, Before Sunrise

# Horror fan profile
horror_fan = {"Bruno", [action: 0.3, comedy: 0.0, romance: 0.0, horror: 1.0, sci_fi: 0.2]}
Classification.recommend(horror_fan, Classification.Database.movies(), 5)
# => The Exorcist, Hereditary, The Conjuring, The Witch, It Follows

# Light comedy profile
comedy_fan = {"Carla", [action: 0.2, comedy: 1.0, romance: 0.3, horror: 0.0, sci_fi: 0.1]}
Classification.recommend(comedy_fan, Classification.Database.movies(), 5)
# => Superbad, The Big Lebowski, The Grand Budapest Hotel, Shrek, Hot Fuzz

If any of these return something odd (like a horror film at the top for the romantic profile), it signals that some weight in the dataset is misaligned—which is great, because it gives you immediate feedback on data quality.

Taking It Further: Libraries and Ecosystem Tools

The `similarity` Hex Package

If you'd rather not maintain your own implementation, the similarity library provides battle-tested cosine similarity, Simhash, and Sørensen–Dice calculations. It supports streaming comparisons and handles mismatched attribute sets—elements added don't have to have the exact same attributes:

s = Similarity.Cosine.new()
s = s |> Similarity.Cosine.add("user_a", [{"action", 9}, {"comedy", 3}])
s = s |> Similarity.Cosine.add("user_b", [{"action", 8}, {"comedy", 2}])
s |> Similarity.Cosine.between("user_a", "user_b")

The library also offers cosine_srol/2, which multiplies cosine similarity by the square root of vector length—useful when comparing vectors of different lengths, as it rewards items with more overlapping attributes. The library requires Elixir 1.14 or later.

Graph-Based Recommendations with MeliGraph

For collaborative filtering or "users who liked X also liked Y" scenarios, MeliGraph brings Twitter-inspired graph algorithms to Elixir. Inspired by Twitter's WTF (Who to Follow) and GraphJet systems, and by Oban's OTP patterns, MeliGraph provides:

Personalized PageRank via Monte Carlo random walks
SALSA for bipartite graphs (hubs/authorities)
SimilarItems with 2-hop co-occurrence and Jaccard/Cosine normalization
GlobalRank for cold-start ranking by in-degree
LightGCN embeddings trained with Nx.Defn + BPR loss, with automatic fallback to SALSA

MeliGraph is single-writer/multi-reader via GenServer + ETS, supports distributed mode with Horde (opt-in), and is telemetry-first. It requires EXLA for optimal LightGCN performance and uses Nx as a mandatory dependency.

Here's a quick start:

# Start an instance
{:ok, _} = MeliGraph.start_link(
  name: :my_graph,
  graph_type: :bipartite,
  testing: :sync
)

# Insert edges (user → content)
MeliGraph.insert_edge(:my_graph, "user:1", "post:a", :like)
MeliGraph.insert_edge(:my_graph, "user:2", "post:a", :like)
MeliGraph.insert_edge(:my_graph, "user:2", "post:b", :like)

# Get recommendations
{:ok, recs} = MeliGraph.recommend(:my_graph, "user:1", :content,
  algorithm: :salsa, seed_size: 10, top_k: 5)

Numerical Computing with Nx and Scholar

For larger-scale scenarios, Nx (Numerical Elixir) brings tensor operations and GPU acceleration to the language. Cosine similarity in Nx looks like this:

defmodule CosSim do
  import Nx.Defn

  defn cosine_similarity(a, b) do
    left = Nx.sqrt(Nx.sum(a ** 2))
    right = Nx.sqrt(Nx.sum(b ** 2))
    Nx.sum(a * b) / (left * right)
  end
end

The Elixir community recommends using Scholar's CosineDistance and subtracting from 1 for similarity. Scholar also provides a BruteKNN module for brute-force k-nearest neighbor search, which accepts :cosine as a distance metric:

iex> data = Nx.tensor([[1, 2], [2, 3], [3, 4], [4, 5], [5, 6]])
iex> model = Scholar.Neighbors.BruteKNN.fit(data, num_neighbors: 2)
iex> query = Nx.tensor([[1, 3], [4, 2], [3, 6]])
iex> {neighbors, distances} = Scholar.Neighbors.BruteKNN.predict(model, query)

With EXLA as the backend, these operations can run on GPU. Scholar is still in pre-release, so you may need to pull it manually from GitHub.

Vector Databases for Scale

For production-scale similarity search over embeddings, dedicated vector database libraries are emerging. The vector-db-elixir project enables fast exact k-NN search over stored vectors with configurable distance metrics (cosine, L2, dot product), eliminating manual matching and enabling real-time recommendations. Similarly, hnswlib provides an Elixir binding for the HNSW library with cosine similarity support.

Practical Considerations

Performance at Scale

The Elixir community has learned hard lessons about scaling similarity calculations. At around 5 million records, loading all data into memory becomes impractical—pushing computation to the database is recommended when possible. For intermediate scales, Flow or GenStage can parallelize the work across cores. For very large lists (over 10k items), consider using Matrex for dot products or leveraging pgvector in PostgreSQL for vector similarity search.

Data Quality Observations

Two things stand out in practice:

1. Genre dominance. If one genre axis (like sci_fi) has high values across many items, any user with a high preference for that genre will see almost exclusively those items at the top. To encourage diversity, consider normalizing each dimension (dividing each feature by its dataset mean) before computing cosine similarity.

2. Near-identical vectors. Films like The Godfather and The Godfather Part II may have identical weights, making them indistinguishable. Adding a secondary feature (release year, director, popularity) as a tie-breaker resolves this.

Adding Diversity to Results

If you want to avoid monothematic lists, apply a simple diversity filter—for example, at most 2 films per dominant genre:

def recommend(user, movies \\ @movies, top_n \\ 10) do
  user_vector = user |> prefs() |> to_tuple()

  movies
  |> Enum.map(fn movie ->
    {name(movie), :math.sqrt(cosine(user_vector, movie |> prefs() |> to_tuple()))}
  end)
  |> Enum.sort_by(fn {_, s} -> -s end)
  |> Enum.reduce({[], %{}}, fn {title, score}, {acc, counts} ->
    genre = dominant_genre(title)
    if Map.get(counts, genre, 0) < 2 do
      {[{title, score} | acc], Map.update(counts, genre, 1, &(&1 + 1))}
    else
      {acc, counts}
    end
  end)
  |> elem(0)
  |> Enum.reverse()
  |> Enum.take(top_n)
end

This keeps the list varied without sacrificing much relevance.

A Practical Roadmap

Here's how to evolve your simple recommender into a production system:

Stage	Approach	Tools
Prototype	Content-based filtering with cosine similarity	Your `Classification` module
Small scale	Add collaborative filtering via co-occurrence	MeliGraph `SimilarItems`
Medium scale	Matrix factorization for latent features	Matrex SVD, Nx tensors
Large scale	Neural collaborative filtering	Nx + Axon, Scholar metrics
Production	Real-time serving, A/B testing	Phoenix, Oban, FLAME

Conclusion

Elixir offers a uniquely pragmatic path to building recommendation systems. You can start with a 60-line module that runs in any IEx session, then scale up to graph algorithms, tensor operations, and GPU-accelerated neural networks—all without leaving the language.

The key insight is that recommendation systems are fundamentally about data transformation: user preferences → similarity scores → ranked items. That's a pipeline, and pipelines are what Elixir does best.

Whether you're building a movie recommender like the one above, a product suggestion engine for e-commerce, or a content feed for a social platform, the functional, concurrent, and fault-tolerant nature of Elixir gives you a solid foundation to start simple—and the ecosystem to grow sophisticated when you need to.

DEV Community: Matheus de Camargo Marques

A SEDA Web Server in Erlang: When an Architecture Paper Becomes a Teaching Exercise

A SEDA Web Server in Erlang: When an Architecture Paper Becomes a Teaching Exercise

What SEDA actually proposes

Why Erlang is the natural substrate for SEDA

The three-stage exercise

Stage 1: The acceptor

Stage 2: The request queue and processor pool

Stage 3: The response queue and writer

Supervision: the glue that makes it resilient

What the exercise actually teaches

1. Backpressure is explicit

2. Failure isolation is structural

3. Stages can be scaled independently

4. The queue is the control boundary

From exercise to verification: the next step

Conclusion: architecture as a teaching tool

Verifying Actor Systems: Beyond Testing

Verifying Actor Systems: Beyond Testing

Why testing actor systems is not enough

1. Runtime verification: ACTORCHESTRA and WALTZ

2. Formal deadlock detection: DDMon

3. Static protocol typing: NVLang

How the three fit together

The academic connection: verification as the end of a pedagogical arc

Conclusion: from “it seems fine” to “we have evidence”

OTP Supervision Is Not a Pattern You Can Copy: Lessons from *Supervision Without Blocking* (2026)

OTP Supervision Is Not a Pattern You Can Copy: Lessons from Supervision Without Blocking (2026)

The audit: 24 defect classes, one root cause

Why OTP supervision works: the blocking supervisor

The unpaid price: push-based lifecycle signaling

The redesign: paying for the trade deliberately

What ANON adds — and what it cannot

The academic connection: why this matters for teaching and for engineering

What this means for practitioners

Conclusion: contracts, not cosmetics

Erlang Actors vs Java Virtual Threads: What Staroletov (2026) Teaches Us About Concurrency Design

Erlang Actors vs Java Virtual Threads: What Staroletov (2026) Teaches Us About Concurrency Design

The concurrency renaissance

What Java virtual threads actually are

What Erlang processes actually are

The real difference: fault isolation

Hierarchical supervision: OTP as a design pattern

What virtual threads do not give you

The pedagogical angle

So which should you use?

Conclusion

From `if` to `verify`: How to Actually Teach Erlang (from Refactoring to Actor System Verification)

From if to verify: How to Actually Teach Erlang (from Refactoring to Actor System Verification)

The problem: the “imperative accent” in Erlang code

Step 1: Refactoring — eliminate the commas

Step 2: Recursion with Taylor series — breaking the factorial/Fibonacci mold

Step 3: Lightweight processes — the “wow” that changes perspective

Step 4: Verification — Promela as a logical continuation of the actor model

Step 5: The end-to-end lab — a system that evolves

Bonus: Erlang in the age of generative AI

Conclusion: a progression that respects the student’s cognition

Practical Erlang/OTP Tutorial Based on Recent Academic Evidence (2025–2026)

Practical Erlang/OTP Tutorial Based on Recent Academic Evidence (2025–2026)

1. Why Erlang? The Academic Rationale

2. First Steps: Refactoring from Imperative to Functional

Exercise 1: From an imperative loop to a recursive function

3. Lightweight Processes and Massive Concurrency

Exercise 2: A TCP server that supports thousands of connections

4. OTP: Supervision and Fault Tolerance in Practice

Exercise 3: A supervision tree for a counter

5. Verification of Actor Systems: Going Beyond Testing

5.1. Runtime Verification with ACTORCHESTRA

5.2. Formal Deadlock Detection with DDMon

5.3. Static Protocol Typing with NVLang

6. Integrative Case Study: A SEDA Web Server in Erlang

7. Conclusion and Study Roadmap

Erlang in 2026: OTP 29, Automotive Expansion, and the Talent Gap Keeping Salaries at the Top

How Social Media Algorithms and Search Engines Work — and What That Means for Erlang’s Digital Space

How Social Media Algorithms and Search Engines Work — and What That Means for Erlang’s Digital Space

Part 1: How social media algorithms work

The universal principle: rank, don’t just publish

The dev.to case: a community algorithm, not a vanity algorithm

The YouTube case: session satisfaction above all

Part 2: How search engines work (Google)

OTP Supervision Is Not a Pattern You Can Copy: Lessons from Supervision Without Blocking (2026)

From `if` to `verify`: How to Actually Teach Erlang (from Refactoring to Actor System Verification)

The `similarity` Hex Package