Erlang processes and message passing explained

Why Erlang processes feel different

An Erlang process is not just a smaller operating-system thread. It is a separate unit of work with its own mailbox and state boundary. That means one process cannot silently mutate another process’s data. Communication becomes explicit because the only normal way in is through messages.

This is one of the biggest reasons Erlang systems are easier to reason about under concurrency. Ownership stays local. Coordination happens through protocols. Hidden shared-state bugs become much less common.

What message passing gives you

Message passing makes boundaries visible. If one process wants information from another, it has to ask. If it wants to update state, it has to send a request in a defined format. That creates clearer APIs and cleaner ownership.

For beginners, this is the right way to frame concurrency in Erlang: not “many things happening at once” but “isolated actors collaborating through messages.” Once that idea lands, OTP makes much more sense.

Pid = spawn(fun() -> loop(0) end).
Pid ! increment.
Pid ! {get, self()}.

How a process loop works

A stateful Erlang process is often just a recursive loop around receive. It waits for messages, reacts to one, updates its local state if needed, and calls itself again. The recursion keeps the process alive while preserving the idea that state is passed forward explicitly.

This is a crucial bridge between recursion and concurrency. Instead of thinking about a while loop over a mutable object, think about a process receiving one message at a time and moving to the next state version.

Common beginner mistakes with processes

A common mistake is treating a process like an object instance with direct field access. Another is forgetting to reply to the caller in request-response patterns. Learners also sometimes send vague messages that do not form a stable protocol.

The best fix is to design message shapes clearly. Use tuples such as {get, From} or {put, Key, Value}. State what each message means, what reply it expects, and whether the process should change state afterward.

What to practice next

• Write a tiny loop that handles one increment message.
• Add a {get, From} message that replies back.
• Name the process owner of the state in one sentence.
• Then continue to OTP basics.

Frequently asked questions