So much this. This "actor model" thing as described by GP sounds like plain old OO and RPC with extra steps and also distributed. This may be a low-effort post on my part, but I'm 100% not impressed because it sounds like marketing fluff and an opportunity to rewrite native/built-in things using frameworks. Also justifying Yet Another Framework or tool hosted on an .IO domain (snarky I know) for promotions and endless blog posts.

Erlang is decades old, a highly successful (for a relatively niche language, anyway) proof that the actor model (or something approximating it) can be a great tool.

CSP/actors is from the 70s, like most CS. It is sort of the original OO, but that's because OO is a newer version that's both less powerful and over-complicated.

It doesn't need to be distributed, and it's better not to include that because the approach to error handling gets a lot easier. If you're distributed every call can fail, be randomly slow, has marshaling costs, is untrusted, etc.

I don't know what you mean by "rewrite native/built-in things using frameworks", the things you are talking about require using frameworks. You need a framework for RPC. You also need a framework for distributed shared memory.

Smalltalk is like this, and Objective-C by following on Smalltalk's design, had a great experience for writing distributed applications on NeXTSTEP.

Agreed, although it’s not always fire-and-forget (i.e. send a message and don’t wait for a response). Actors generally do support request/response style messaging, but it’s always async - it’s really only synchronous request/response communication that’s not allowed.

Not always. Goblins[0] is an example of an actor system that supports both synchronous and asynchronous communication between actors, with synchronous communication only possible if both actors are in the same “vat” (a kind of event loop).

[0] https://docs.racket-lang.org/goblins/

Hi! Yeah I'm the author of Goblins :)

Yes, Goblins' "vat" model descends from E, which supports the "hybrid worldview". http://www.erights.org/

I have a tendency to call Goblins objects "actors", though some people in the community like to point out that "distributed object" is preferable since synchronous call/return is not supported in actors. But yeah.

> Agreed, although it’s not always fire-and-forget (i.e. send a message and don’t wait for a response).

Sure, you can do async request/response in the actor model, but the low-level basic mechanism all communication is built on is send a message to an actor mailbox and keep going. Everything else is built in top of that.