Experience shows that it really isn't. The fundamental issues of non-deterministic ordering are inherent in the domain that Erlang was designed for, and the VM characteristics pretty closely reflect that. It turns out that people have comfortably written complex and scalable commercial systems in Erlang for decades, and many have noted that for people who understand the problem domain, the Erlang model feels intuitive.
The problem of message order non-determinisim is real, but for orchestration logic in scenarios with multiple uncoordinated message sources, it's inescapable. What is important is that the programming environment helps you deal with it, and doesn't introduce additional - "accidental" - complexity.
I discussed this topic at QCon 2010, and ran through some demos to illustrate where many commercial projects actually DO go wrong, and why the textbook Erlang model keeps you safe.
The key guarantees that Erlang gives you here are:
* Messages from A to B will all arrive (if they arrive) in the order in which they were sent, and you can detect if there is an interruption
* A receiving process can decide in which order messages are processed.
It turns out that people intuitively understand that if Alice and Bob each send me a message, independently of each other, I cannot know which message reaches me first. This mirrors a fundamental real-world constraint, and in a distributed processing environment, there really isn't much you can do about it.
There are other concurrency-related problem domains, some for which the Erlang implementation, at least, is not ideal.
In practice, one will have to refrain from some of the crazier stuff when working interactively in the shell of a production system. However, it's extremely useful for debugging and minor adjustments by a skilled engineer. Things you can do include inspection of data structures, (very) careful tracing, loading of instrumented modules or minor corrections.
Since Erlang is dynamically typed, practically all data structures can be inspected at run-time, and one particularly nice thing about the Erlang shell is that it tends to be responsive even when the system is operating at near-maximum load.
To say that Erlang fails to deliver what most programmers need misses the point. If you have a mainstream problem, use a mainstream language!
I've spent many years developing and reviewing products in the telecoms realm, and have found that failing to realize when something like Erlang brings life-saving concepts to your project may well make the difference between delivering on time and disappearing into a black hole of endless complexity. It's not for everyone, but when it fits, boy does it help!
Ericsson could have had a need for multicore already back in 1997, when the first SMP Erlang prototype was written, but the space and power budgets for the processor boards made it impossible to get any matching hardware for it. SMP in those days was not multicore, but several CPUs. It was only usable in servers - not in embedded systems.
The problem of message order non-determinisim is real, but for orchestration logic in scenarios with multiple uncoordinated message sources, it's inescapable. What is important is that the programming environment helps you deal with it, and doesn't introduce additional - "accidental" - complexity.
I discussed this topic at QCon 2010, and ran through some demos to illustrate where many commercial projects actually DO go wrong, and why the textbook Erlang model keeps you safe.
https://www.infoq.com/presentations/Death-by-Accidental-Comp...
The key guarantees that Erlang gives you here are: * Messages from A to B will all arrive (if they arrive) in the order in which they were sent, and you can detect if there is an interruption * A receiving process can decide in which order messages are processed.
It turns out that people intuitively understand that if Alice and Bob each send me a message, independently of each other, I cannot know which message reaches me first. This mirrors a fundamental real-world constraint, and in a distributed processing environment, there really isn't much you can do about it.
There are other concurrency-related problem domains, some for which the Erlang implementation, at least, is not ideal.