It's helpful to keep in mind some parallels between actor systems and inheritance hierarchies.

- The tendency is to start extremely elaborate and become much more minimalistic with experience.

- The educational materials do too good a job at explaining advanced techniques without warning about how important it is to keep things simple in practice.

- A complex actor system or inheritance hierarchy should both reflect AND help tame complexity in the problem you're solving. If it doesn't meet both of these criteria, it should be simplified.

- There is no semantic reason that any relationship in a problem domain needs to be modeled by inheritance or actors despite being painful to program that way. The technique should only be applied where it helps.

I think (not from personal experience, but from what I read) that the big exception to the above is when you're using actors to optimize latency or throughput on a big multi-core machine. Then you will find yourself taking on complexity for the sake of maximum performance. I think educational materials often present techniques from these difficult, carefully-built systems as if they're helpful for writing simple, small services. This is also a parallel to inheritance, if you take a step back: high-performance data processing systems are the canonical problem for this era, just like complex native GUI programming was the canonical problem in the heyday of big inheritance hierarchies. Lessons from those domains can be misleading when applied to simpler problems.

I worked on a hierarchical, distributed control system written in Erlang, and I found the actor model well suited to that problem domain.

We had to control various devices based on sensor data, but we also needed to make sure that the workload was distributed across the devices in an efficient way. To implement that, we had one actor per device that was solely responsible for adjusting the device output based on sensor data. Then we had another actor that was responsible for looking at the behavior of a cluster of devices and distributing the load between them. This "load distribution" actor wouldn't control the devices directly, but instead would send adjustments to the actors directly controlling the device.

I find it very natural to anthropomorphize actors. That is, if you were to think about how you would organize a group of people to do the work of the system (in a very Taylorist sort of way) the roles of those people map neatly onto the actors one would create.

One common pattern is the manager/supervisor/worker pattern[0]. I see this as mapping fairly neatly onto the project manager/people manager/employee structure that you see in many organizations.

[0] https://zxq9.com/archives/1311

I think what most people want to know is whether they could re-write a multi-threaded program that is currently using synchronization primitives (locks, semaphores, mutexes, etc) with actors.

Like, show me the producer-consumer pattern using actors.

I mean, that's a pretty standard actor pattern..

https://github.com/foobatman/producer-consumer-akka-actor/tr...

There are many more examples out there. Anything that a multi-threaded program can do, an actor can do..

I just think that actors are inherently more complex than threads for simple problems. For complex problems, I think actor are probably a better choice.

A good example of a simple program is managing multiple TCP connections. At least in my (somewhat limited) experience with actors, polling TCP file descriptors is easier to manage creating an actor for each one.

> I think what most people want to know is whether they could re-write a multi-threaded program that is currently using synchronization primitives (locks, semaphores, mutexes, etc) with actors.

Really, it's not obvious? Of course you can: instead of shared memory you now have each actor having its own memory, instead of using locks and working on shared memory you now have messages and can ask actors to do something with their memory and send you the result back.

You just have to think a bit differently about your synchronization primitves. You don't have locks, you have a message queue and that is your synchronization primitive. A resource that should only be accessed by one thread is abstracted away using an actor, and the queue guarantees that only one process at the time has access, as the actor can only process one message at a time.

You can implement locks using actors if you really want to. An actor represents the state of the lock and stores which actor locked it and only responds to the unlock message from that actor and ignores all lock and unlock messages from all the other actors until it is unlocked.

Does this satisfy you ? https://github.com/elixir-lang/gen_stage

"You end up with a big graph of actors" - you are almost certainly doing something wrong, the actor graph shouldn't need to be "big", and the supervisor hierarchy almost never deeper than 2-3 levels. A typical mistake when doing actor-based system design is to think that actors are replacements for modules or classes (or taken to the extreme: function calls), which is not the case.

Massive Inconsistency Robust Ontologies will have trillions of Actors on a many-core computer.

Please see the YouTube video here:

  http://web.stanford.edu/class/ee380/Abstracts/190123.html

Didn't watch the video, but as I understand actors is that you can have trillions of instances of your actors, but you're not having a large number of actually different actors. For example let's say you have a server that handles requests. You implement the request handler as an actor and for every request you spawn an instance of that actor to handle that request.

There will be zillions of different kinds of Actor in a massive inconsistency robust ontology, each with a different implementation although constructed on a common system.

According to Carl Hewitt, the actor model is based on physics (especially quantum physics). Doesn't this then imply that the natural scope of such a system entails huge numbers of actors, interacting in a probabilistic way?

So in order to understand our systems with huge graphs of actors, we should attempt to develop something akin to the heat equation for actors. Trying to understand the behaviour of every individual actor in the context of the whole system is just too much.

I will admit that I do not have much experience creating actor systems. But the actor model in inherently complex. To be fair, that's because it's trying to solve a complex problem. But unless you actually need thousands of concurrent processes, often you can do without it.

I played with erlang at uni, and now I'm working with scala, and I find the latter very messier than the former

Scala and Akka are... less simple. It's also not like the actor model takes over the whole paradigm. Actors are largely a runtime concern. You're still using modules and functions. The JVM is also less suited to implementing an Actor model. A lot of the BEAM's power comes from the preemptive scheduler.

That (the preemptive scheduler) and OTP/gen_server, which covers about 90% of the cases Erlang should be used for anyway. These are the foundations of Erlang-land, however, sadly neither of those have equivalents in Akka or on the JVM.

I have a long time been a evangelising concurrent ml. It generalises the actor model, and for me it has always hit the sweet spot between "do everything yourself" and "one inflexible way or the highway".

IIRC, it tries to "generalize" CSP, or rather just make it usable, because it isn't in its default form at all. CSP is not as general as actor model. But you can't generalize actor model into a more general concurrency model, unbounded nondeterminism is as far as we can go.

Actually, the Actor Model generalizes Concurrent ML because message and types are Actors.

For example, if anAccount:Account then the following

     anAccount.deposit[$5]

is defined as follows:

     Account.send[anAccount. deposit[$5]