[lostcolony]

>> Erlang: solves the problem, but the actor formulation is too awkward for all but Erlang-specific use-cases.

Err? I mean, it requires rethinking a bunch of the lessons you learn when concurrency is hard and expensive and to be minimized, sure. But when concurrency is easy and cheap and to be embraced, a bunch of things become a lot easier and more natural to write.

My go to example, from a production system, was a complicated task scheduling system (with user and hardware interrupts to handle). Sure, we could have written it using threads and a priority queue or something...instead we just had one Erlang process per task, with interrupts routed to that process as messages (and linked timer processes that fired messages to those processes for the scheduled stuff, essentially just another type of interrupt/message). Super simple to write, super simple to reason about, never had any sort of race condition or locking issues, across years of development and production use.

[kcl]

The problem with concurrent computing is not a lack of Erlang awareness or message passing awareness. If either was the solution we wouldn't be having this discussion since they both pre-date the 90s.

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.

[lostcolony]

There are plenty of shortcomings of Erlang. They even post a bunch on the main website - https://www.erlang.org/faq/introduction.html#idm53

-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?

[rramadass]

>The problem with concurrent computing is not a lack of Erlang awareness or message passing awareness

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.