Is there any resource that can help me properly understand the actor model and make an informed decision on whether it's something everyone should have in their toolbelt or just another technology like blockchain, in search of non-scam usecases with mainstream appeal?
The actor pattern is used quite a bit in the functional world (Akka is pretty popular in the Scala ecosystem). It's just a design pattern that lends itself well to distributed applications with complex communication structure like some microservice systems. Some
people use it to represent graph-like data structures with nodes that update themselves based on their neighborhood, though that's kind of gimmicky. There's no connection at all (that I'm aware of) to crypto or fintech scams, and I guess it doesn't hurt to have a look at the actor pattern if you're in a functional language; always good to know what tools exist.
Actors have been used since the 90s for distributed programming, in particular at telcos. To a large extent, microservices are a poor man's reimplementation of actors, with all the drawbacks and not many of the benefits.
Not scam or even fad. It’s legit. However, details vary so I agree with the sibling that “design pattern” is the best classification for it.
I think it’s fair to say that the actor model is analogous to FP, but for distributed (and to a lesser extent multithreaded) computing. Just like FP has friction against imperative programming, there is a similar friction when interoping with traditional systems. Likewise, benefits pile up once you have some critical mass of subsystems that all use the actor model, where certain problems just go away.
I’m personally a big believer, it fits my mental model as I like to think about data flows first. That said, almost all systems today are request-response, so you have to either accept a certain amount of friction or embrace the much smaller ecosystem of message-based systems.
Just like regular programming is going more and more multi-paradigm, incorporating FP and others into mainstream langs, it seems like the distributed world is moving slowly in a multi-paradigm direction as well. For instance, databases and file systems are increasingly using message/event streams and sometimes exposing them directly to users.
It is definitely in the "everyone should have it in their toolbelt" class. It is one of the fundamental primitives that makes multithreaded programming a sane and sensible thing that almost anyone can learn and do, rather than an insane hellscape of locks. It is not the only such primitive, but it is one of the basic ones.
At the core, this is an actor: Just as an object fundamentally binds some bit of data to some set of methods that operate on it, an "actor" is a binding of a thread to some data, such that no other thread will ever access it. Therefore, there is no locking problem on that data and the actor has full control over it. It embeds an island of single-threaded processing in a sea of multithreading. It's a "server" with all the reductions in complexity you can apply to it for being in process rather than an external process communicated with via some stream.
As with objects, you can elaborate on that theme in a number of ways. You can enforce at the language level that actors have unique access to certain data (Erlang/Elixir, Pony). You need some communication system; you can bless one as part of the language runtime (Erlang/Elixir mailboxes, Go channels). You can build in support for various structures on top of official actors just as you can build support for various object structures once you have an official concept of an object, like supervisor trees and crash notification (Erlang/Elixir). You can provide actor-level polymorphism by defining protocols they have to conform to. You can embed actors into a structured concurrency model (no language yet [1], as far as I know!) to create a "structured actor" model.
However, just like objects, you get hordes of people insisting that their way is the one true way of doing actors and if you can't check off EVERY LAST BULLET POINT FEATURE of their preferred implementation you don't have actors. I imagine what you are picking up about actors are these people, who come away thinking that if you aren't Erlang, you aren't using actors. These people are wrong, just as people who think that if you aren't exactly Java you don't have objects. Actors at their core are very simple; really the only thing you have to have to get them right is to make sure that an actor's data is only accessed from one thread. Just as I tend to take an expansive view of "object orientation" that it is simply about having "methods" of some sort attached to data structures and I don't sit there and argue about how you need to have a "protected" key word and all the structure that implies to have an object system.
While language support for completely rigid isolation of data to a thread is nice in some ways, it is not necessary, and it can also sometimes be a problem if you want to do something else; it is not hard to accomplish the goal with other tools. For instance, in most object oriented systems you can accomplish this with a factory/constructor function that creates an object and spawns its associated thread, using some variant of "private" to make it so only that thread ever receives access to the internal data. I'd even consider that second clause optional in the case of a language like Python, where private-ness is more convention than strict enforcement. But push comes to shove, nothing stops you from writing actors in C, just as you are not stopped from writing objects in C. You just get zero language support.
In fact everything in the paragraph about what you can build on top of actors can be built as libraries. It's just that the tradeoffs vary from system to system. I implemented supervisor trees in Go, for instance. They aren't exactly what is in Erlang, but they largely solve the problems I have. A language may not have support for an "actor protocol" but using an object oriented language's concept of polymorphism allows a rough equivalent through implementing methods that encapsulate communication with the actor does roughly the same thing and solves the same problems. It isn't always perfect, but there's never a perfect solution to every problem in a given language. Having perfect actors implies some other weaknesses somewhere else.
So, yes, the concept of binding data to threads is a critical one to building modern systems. While I generally phrase the errors of the 1990s threading hell world in terms of their locks, a complementary view is to say that the screw up of our first pass at threading, with the attendant fear still echoing through our community to this day, was the attempt to allow all threads access to all data all the time. When you don't do that, you don't get the threading hell of the 90s. Actors are not the only solution to the problem, but binding data to specific threads is one of the basic tools in solving it. Extremely important to sane multithreaded programming.
[1]: Yes, this includes Erlang; in Erlang you can still "spawn" whenever you feel like it. It is true that usage of the OTP library encourages things that look like "structured concurrency" but it does not enforce it, nor does it take advantage of some of the things that structured concurrency would allow. And I'm talking about languages and their strict enforcement here, and as basic as OTP may be, it is still a library.
Here's the chapter "Message Passing and Actors" from the Programming Models for Distributed Programming book by Nathaniel Dempkowski, comparing different types of actor models:
I would also say that matches the academic viewpoint fairly well. It shows how my reductionistic view of actors as the important thing being the binding of data to a specific thread of execution is a fairly heterodox view. I don't want to hide that. Note how that link does discuss data, but it isn't anywhere near as front-and-center as I would put it. If I were writing a similar survey, it would probably be my organizing metaphor, rather than message passing. I'm not criticizing that organization; it's a completely valid handle on the problem as well. It's just not what I would use.
At the end, they disclaim Communicating Sequential Processes as not being an actor model. By their terminology, this is correct. By my heterodox view, though, I would still put them under the "actor" category, at least in general (I don't know if it's strictly speaking necessary for the processes to have isolated data, but even if not specified one does wonder what the point of all the communication is on a practical level if the processes can just reach in to each other's data sets), and to me they would be another example of the various elaborations you can apply to them.
Ultimately what kept me out of academia is I had too much of a hybrid engineering/academic view to fit into either one comfortably, and I could tell there wasn't much room for an "in between" all protestations to the theoretical desirability of cross-discipline cooperation notwithstanding. There's a sense in which all the details in that link matter. But there's another sense in which 75% of the problem is solved just by ensuring that you've got some data that can only be accessed by a given thread of execution, another 20% that you can't hardly help but solve beyond that (e.g., you will come up with some sort of messaging solution, and the details of that solution may affect your architecture but broadly speaking any half-sane solution will generally be able in some way to solve any problems you have somehow), and the remaining 5% is academically interesting but from an engineering perspective will generally only start to bite you at very large scales, so are only worth worrying about if you expect to scale that far. The latter point of view is... not the common approach academics take.
But you don't need to worry about a lot of that stuff to just get started. The guidelines I've given in these couple of posts will get you the vast bulk of real value with a fraction of the concepts, and while you will need to choose some sort of system to use your actors, the complexity is less than it appears because most of the time any of these solutions will work for you, or you'll be choosing them on completely other criteria like implementation language or network protocol compatibility.
