Reading about concurrency in Erlang, reminds me of the Akka concurrency toolkit. Both give you tools to prevent or limit race conditions. But you can send links to mutable data to other processes using the Akka toolkit, which is still unsafe. I see Akka as a useful tool, but it does not provide protection against out-of-order access to objects and data leading to race-conditions, deadlock, and/or starvation. It doesn't prevent you from writing unsafe code the way Java or C# protects you from writing most of the kinds of memory leaks you can write in C++ (you can still create memory leaks in Java by tricking the garbage collector, but it is less of a problem than having to remember to free every byte you allocate).

Does Erlang guarantee a degree of correctness, performance, and robustness in concurrent programming? I think operating systems provide protection when accessing system resources (assuming the driver writers did their jobs well). ACID databases provide protection for reads and updates. So it seems this is a solvable problem. Or would a generic safe solution would erase the performance gains that concurrency provides? Do other languages or toolkits provide the kind of concurrent safety that Erlang does (or doesn't)?

This is a follow-up question to @Malfist's comment on @user1249's answer to What programming language generates fewest hard-to-find bugs?.

1 Answer 1


There are a few things that Erlang does to help with these.

  • Data is immutable, so no data races
  • OTP gen_servers and gen_fsm's provide a very well tested pattern for servers
  • Supervisors allow for recovery from crashes
  • processes are small and cheap
  • Memory is allocated on a per process basis (no GC freezes)
  • the erlang VM is optimised to work under very heavy loads
  • Software can be updated on the fly, so no upgrade downtimes

The major thing here is that in Erlang there is no shared state that could require a lock, so there is no need for locks. It is a brilliant language for soft real time applications that need no downtime and high fault tolerance and concurrency

  • 13
    @JarrodRoberson: Actually, the main point is no shared mutable state. Sharing state is no problem if you don't mutate it. Mutable state is no problem if you don't share it. Commented Jan 22, 2013 at 16:05
  • 1
    There is also a new tool Concuerror youtube.com/watch?v=FpkjKN9wTKg which lets you run your tests with all possible event orderings
    – Zachary K
    Commented Dec 9, 2013 at 15:53
  • I still have difficulty understanding how immutable shared state prevents out-of-order state update? Let's say two requests tries to update the same value - which one will win? Commented May 26, 2023 at 17:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.