> I haven't seen a cure yet that's better than the problem.

Ok, I have. Been using Erlang in production, full time. I see benefits every day:

* State manipulation is clear and explicit. No giant class intances that somehow ended up in a funky state. No trying to figure out which inhereted class or which sequence of 50 method call got it into that funky state.

* Immutability by default for data. I have spent too many days tracking down Java and C++ share memory concurrency issues to want to do that again.

* Already built in high level concurrency primites -- message passing, lightweight processes, ability to send a message to a remote node, state machine modules, event distribution (listener-observer thing in other languages).

* Fault tolerance -- very well defined and first class error handling. Errors are confined and isolated to parts of the system and are guaranteed to not spread. With C++ you don't know if your crashed thread, hasn't scribbled over memory and restarting just that thread is safe. The only safe thing is to restart the whole service. Except there are 100k connected clients to it, now you have downtime and nowyou have long hard road ahead debugging the problem.

* Hot code replacement. Yeah seems like a gimmik and many users I understand don't use it to upgrade as regular mechanism. But it is really invaluable to quickly fix a patch on a running system for a particular customer with 0 downtime, or to hotpatch a function to get better logging.

These might seem like academic generalities, but I've seen in practice these translate to a better uptime, lower ops load, less engineers salaries needed to be paid, less code (Erlang is like a DSL for distributed system, and it just happens that systems we use today are distributed). At the end of the day all that means money saved and more bread on the table at the end of the year.

> I think the downfall of some of these languages is that they get wrapped up in being "functional" rather than focusing on solving a particular class of

Not true for Erlang. When Joe and Robert were writing Erlang, I understand they never got wrapped up in academics papers and didn't even know about "actors", didn't explicitly went for "functional first". They went for soft-realtime and fault tolerant. "Functional" part with immutability just fell out of "fault tolerant" requirement.

> You can have an actor model architecture without using a functional programming language. You can avoid shared state in any modern language (even JavaScript). These things are not synonymous with functional programming.

You can. You can even have live code replacement in Java. But it is not the same. You can slap a thread safe queue + a thread and call your framework a "an Erlang killer" but unfortunately concurrency and message passing is secondary to fault tolarance. That shared state and that thread cand still use a library which scribbled over memory of anothe thread.

> the cases where a functional programming language are really the best solution to the concurrency problem are, in fact, rather rare.

Maybe they are rare. But it is really the secret sauce when they match. Yeah, you have to type . instead of ; at the end of statement and have to use recursion in intead of for loops. If that is hard or insurmountable, don't use it. Use something Java, C++ or Go. Those can get stuff done to.

Even better can give Elixir a try has the same VM as Erlang and a really friendly community. So if typing . intead of ; is hard and seeing capitalized variables looks irritating, give that a try.