# The Isolation Trap: What Erlang shows about the limits of concurrency through isolation (repost) **URL:** \ **Category:** Chat / Discussions\ **Tags:** erlang, erlang-otp\ **Created:** [March 12, 2026, 12:48pm UTC](https://erlangforums.com/t/the-isolation-trap-what-erlang-shows-about-the-limits-of-concurrency-through-isolation-repost/5487 "2026-03-12T12:48:15Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![phild](https://erlangforums.com/user_avatar/erlangforums.com/phild/32/742_2.png) [@phild](https://erlangforums.com/u/phild)\ **Post date:** [March 12, 2026, 12:48pm UTC](https://erlangforums.com/t/the-isolation-trap-what-erlang-shows-about-the-limits-of-concurrency-through-isolation-repost/5487/1 "2026-03-12T12:48:15Z")
I found this an interesting read. > We’re continuing to look at the state of concurrency in programming languages and identifying what’s wrong with it. As a reminder, in [Message Passing Is Shared Mutable State](https://causality.blog/essays/message-passing-is-shared-mutable-state) I argued that Go’s channels are shared mutable state with extra steps. But you may think Go’s channels aren’t true message passing. The honor for “best case for message passing” probably falls to Erlang. So let’s look at Erlang. > **[The Isolation Trap — Causality](https://causality.blog/essays/the-isolation-trap/)** > > Erlang's mailbox design is more disciplined than Go's channels: only the owning process can read from a mailbox, and sends are asynchronous. Yet the four failure modes of shared mutable state still show up, just in different shapes. ---
**Author:** ![eproxus](https://erlangforums.com/user_avatar/erlangforums.com/eproxus/32/452_2.png) [@eproxus](https://erlangforums.com/u/eproxus)\ **Post date:** [March 13, 2026, 1:36pm UTC](https://erlangforums.com/t/the-isolation-trap-what-erlang-shows-about-the-limits-of-concurrency-through-isolation-repost/5487/2 "2026-03-13T13:36:18Z")
It is interesting, but some things are not as bad as they make it out in my opinion. It’s a bit too hyperbolic for my taste. > Forget to set a timeout on a `gen_server:call`? You get a potential deadlock that hides until production load triggers it. That is not true since there is a default timeout of 5 seconds. The example provided would simply ”unlock” itself after that time: ```erlang %% Server A handles a request by calling Server B handle_call(request, _From, State) -> Result = gen_server:call(server_b, sub_request), {reply, Result, State}. %% Server B handles a request by calling Server A handle_call(sub_request, _From, State) -> Result = gen_server:call(server_a, request), {reply, Result, State}. ``` I agree about Erlang getting it right by having the right primitives and sensible defaults, but providing riskier escape hatches when needed. Even though the style of the writing is a bit sensational (is it written by a human? Who can tell these days?). ---
**Author:** ![phild](https://erlangforums.com/user_avatar/erlangforums.com/phild/32/742_2.png) [@phild](https://erlangforums.com/u/phild)\ **Post date:** [March 13, 2026, 2:27pm UTC](https://erlangforums.com/t/the-isolation-trap-what-erlang-shows-about-the-limits-of-concurrency-through-isolation-repost/5487/3 "2026-03-13T14:27:59Z")
I know what you mean. My main takeaway is that this is why you need to understand the idiomatic conventions - and the rationale for them - as well as the syntax of any given language. To put it another way, if you consider a language as if it were a map, there will always be areas that are labelled “here be dragons”. And that IMO is _fine_ because, as software developers, knowing that is our job. ---
**Author:** ![mpope](https://erlangforums.com/letter_avatar_proxy/v4/letter/m/71c47a/32.png) [@mpope](https://erlangforums.com/u/mpope)\ **Post date:** [March 13, 2026, 3:16pm UTC](https://erlangforums.com/t/the-isolation-trap-what-erlang-shows-about-the-limits-of-concurrency-through-isolation-repost/5487/4 "2026-03-13T15:16:12Z")
A fun article that points out very real problems. ```erlang The pure model says “send a message, wait for a reply.” Each reader waits in line, the mailbox becomes a funnel, and throughput collapses. ``` is quite true in the “pure model”, but common tricks (which lines up with what the article says earlier lie with the programmer to know indeed), such as saving the `from` in the gen\_server state, and spawning worker processes to perform async processing, where a gen\_server becomes more of a scheduler itsself, which prevents _bottlenecking_ but keeps _blocking_ say for resource queuing. I’d say I try to reach for this particular “escape hatch” more than ETS. ---
**Author:** ![eproxus](https://erlangforums.com/user_avatar/erlangforums.com/eproxus/32/452_2.png) [@eproxus](https://erlangforums.com/u/eproxus)\ **Post date:** [March 13, 2026, 3:40pm UTC](https://erlangforums.com/t/the-isolation-trap-what-erlang-shows-about-the-limits-of-concurrency-through-isolation-repost/5487/5 "2026-03-13T15:40:54Z")
Again, a bit of hyperbole in the article in my opinion. You can spawn **two** process and suddenly have twice the output! 😉 Erlang gives you very nice building blocks to structure systems with, which I think are much easier than many other tools in other languages I’ve used. But what paradigm or language is designed in a way that bottlenecks are impossible to create? I can’t think of one. ---
**Author:** ![nzok](https://erlangforums.com/letter_avatar_proxy/v4/letter/n/4af34b/32.png) [@nzok](https://erlangforums.com/u/nzok)\ **Post date:** [March 14, 2026, 6:26am UTC](https://erlangforums.com/t/the-isolation-trap-what-erlang-shows-about-the-limits-of-concurrency-through-isolation-repost/5487/6 "2026-03-14T06:26:33Z")
The thing is that Erlang isn’t really a _conchurrency_ model, it’s a _distributed_ programming model. In a distributed system you are GOING to have isolated subsystems communicating by messages that may not arrive. Like it or not. The message I read just before this was about a server down for maintenance and people being unhappy and surprised. At scale,there simply isn’t any other game in town. ---
**Author:** ![josevalim](https://erlangforums.com/user_avatar/erlangforums.com/josevalim/32/353_2.png) [@josevalim](https://erlangforums.com/u/josevalim)\ **Post date:** [March 14, 2026, 4:54pm UTC](https://erlangforums.com/t/the-isolation-trap-what-erlang-shows-about-the-limits-of-concurrency-through-isolation-repost/5487/7 "2026-03-14T16:54:24Z")
I think the article fails in a circular way: if the premise is that message passing is ultimately shared mutable state (which is true), then it should be acceptable to have other forms of shared mutable state, such as ETS and persistent term? Therefore the more interesting question is not what is and what isn’t shared mutable state, but what properties each of these offer. The article covers message passing well but it is wrong about everything else: > They are shared state outside the process model, accessible concurrently by any process, with no mailbox serialization, no message copying, no ownership semantics. While ETS can be accessed concurrently with no serialization (that’s the whole point), data is still copied and it has clear ownership semantics. `protected` and `private` ETS tables belong to the writer process and will terminate when the process crashes, so they remove serialization _while_ preserving isolation. Alternatively, `persistent_term` uses references with well-documented semantics too. Furthermore, as @nzok mentioned, the article misses the biggest point: isolation is also essential for fault-tolerance and distribution. Erlang’s model isn’t claiming to eliminate all shared-state bugs. It’s claiming to give you the best _starting point_, strong defaults with well-designed options for concurrency, fault-tolerance, and distribution simultaneously. ---
**Author:** ![Schultzer](https://erlangforums.com/user_avatar/erlangforums.com/schultzer/32/2859_2.png) [@Schultzer](https://erlangforums.com/u/Schultzer)\ **Post date:** [March 14, 2026, 8:12pm UTC](https://erlangforums.com/t/the-isolation-trap-what-erlang-shows-about-the-limits-of-concurrency-through-isolation-repost/5487/8 "2026-03-14T20:12:48Z")
That article looks 100% AI generated. I guess 2026 is going to be the year where you cant trust anything that does not come with a full replication suite, if the AI hype train is good for anything its devaluing all the trust me brah I wrote a blog people.