There ought to be a codeword where you can invoke the shortcomings of Erlang without getting dragged into a conversation with someone desperate to talk about Erlang. Next time I will rot13 it.
-You- said "But the actor formulation is too awkward for all but Erlang-specific use-cases". I was simply commenting that it's not awkward at all, for all sorts of use cases that aren't Erlang specific. Perhaps you'd like to define your terms better if you want to avoid people saying "hey, that statement as it comes across is flawed". Maybe you meant Erlang isn't the right tool to generalize to all use cases - no one would disagree. Maybe you meant what it sounds like, it's too awkward to use except for certain degenerate cases, in which case I strongly disagree; it's quite easy, and switching back to running N isolated units of execution on < N threads, and sharing memory between them, feels like a chore. Or maybe you meant something else entirely.
Maybe if you don't want to "get dragged into" a conversation on something...don't mention it on a public forum with such a badly worded statement?
It most certainly is.
We have been so thoroughly fed/brainwashed with Shared-Memory concurrency that most people don't even think beyond it unless forced by circumstances (or from curiosity). That is where Message Oriented Concurrency languages like Erlang can help. Just reading Joe Armstrong's thesis Making reliable distributed systems in the presence of software errors will teach one a simple approach to robust Concurrency that works and can be emulated in another language if you don't want to learn Erlang (the difficulty may vary based on language support).
PS: Folks may find Foundations of Multithreaded, Parallel, and Distributed Programming by Gregory Andrews a good reference for most major forms of Concurrency.