He explicitly credited the actor model as one of the major influences on Smalltalk and OOP. The distinction as far as I have been able to tease it out is that in the actor model there is a distinction in kind between actors and values passed among actors. In OOP, there is no distinction in kind, that is, imagine you have an actor-like thing that sends you a reference to something, but that something is going to be of the same category of actor-like thing.

Hewitt created actors after hearing an early Smalltalk talk by Kay at MIT, as I recall it. That wasn't the only influence (capabilities were a big one, for instance) and I'd be surprised if there wasn't reciprocal influence, though.

In Hewitt's actor model, messages are also (immutable) actors. At least in the early version I read about.

Actors were developed to unify and overcome limitations of

previous important contributions including lambda calculus

[Church 1932] (first-class procedures), Petri nets [Petri

1962] (true concurrency), semaphores [Dijkstra 1962-1963],

packet switching [Baran 1964] (concurrent communication

between computers using fixed size packets), capabilities

[Dennis and van Horn 1966] (pointer security), Simula [Dahl

and Nygaard 1967] (class hierarchy), and SmallTalk-72

[Goldberg and Kay 1976] (bit-mapped computer graphics and

browser, the precursor of modern programming Integrated

Development Environments). The lambda calculus could not

express concurrency with the consequence that lambda

calculus programs can be thousands of times slower than

Actors. A Petri net cannot dynamically expand and has the

limitation that tokens can miraculously disappear from

different places, which is inefficient to implement.

Capabilities have the limitation that pointers must be

manipulated using indexes into capability lists thereby

making programming awkward. Simula did not implement

concurrency and did not have messages. SmallTalk-72 used a

byte stream of program tokens thereby making it awkward for

concurrency.

See the following for more information: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3418003

another cyclical influence is scheme trying to reimplement the actor model in a lisp/lambda clothing.

The programming language Scheme was originally named Schemer against Actors ;-)

The monad (https://wiki.haskell.org/Monad) is another mostly unsuccessful lambda calculus way to try to address some of the issues resolved in the Actor Model.

My english is failing me, what's the meaning behind 'schemers against actors' ?

I only knew about actors for its scheme influence and the fact that it was highly concurrent (even this I'm not so sure). I got into college way too late for it to be studied sadly.

The original name of the programming language Scheme was "Schemer", which was shortened by removing the last character because of file system limitations. The motivation for the name Schemer was that the authors were scheming against Actors analogous to the programming Conniver, where the authors were conniving against Planner.

Oh I see the trail goes deep. Interesting.

That had been my conclusions over the years. Erlang (or Elixir) are ironically one of the nicest environments for OO code these days (given they are usually categorized as "functional")

The YC ideation talk with Alan Kay has a small rant from Alan about what he meant with Objects, and how that isn't what objects are used for now. What he described sounds exactly like the actor model.

I can't find the quote online so this could easily be apocrypha or something I made up in my head, but I could have sworn Alan Kay has said as much along the way.

There's a quote from Joe Armstrong saying something like that

> As Erlang became popular we were often asked "Is Erlang OO" - well, of course the true answer was "No of course not" - but we didn't to say this out loud - so we invented a serious of ingenious ways of answering the question that were designed to give the impression that Erlang was (sort of) OO (If you waved your hands a lot) but not really (If you listened to what we actually said, and read the small print carefully).

https://stackoverflow.com/a/11809324/903589

>If a language technology is so bad that it creates a new industry to solve problems of its own making then it must be a good idea for the guys who want to make money.

Oof.

Yes. Erlang probably bears out the actor model best, although there are many library implementations in various languages.

Erlang made important contributions. However, the Erlang model needs the following important extensions:

•Automatically reclamation of storage of an unreachable future [Baker and Hewitt 1977] (e.g. process in Erlang). For example, an Erlang process can be orphaned if its Process Identifier (PID) becomes inaccessible. Also, since Erlang is not strongly typed, cyberattacks can be launched against dangling references to processes that no longer exist.

•Language support for holes in the region of mutual exclusion of an Actor implementation. For example, in Erlang it is necessary for application programmers to explicitly code a message handler for each re-entry into the region of mutual exclusion potentially enabling cyberattacks from outside the process.

Given that a PID can be sent to another node and even serialized and deserialized, it doesn't seem possible to know if it's still referenced in a meaningful way.

For example, if process X on node A sends a message to process Y on node B and the network goes down, that doesn't mean process Y won't send a message to process X when the network resume.

Thanks Toast!

You have made the point exactly. The problem of dangling processes is made worse by the fact that Erlang is not strongly typed.

This can be mitigated by processes not being "objects".

Especially objects that need to be pinned by ref counting.

My personal interpretation of the Actor model is a message passing system to model the real world.

In the real world I can shout out "make me a sandwich" and even if I perceive that there is a process that could potentially satisfy that request, I also work on the assumption that for any number of reasons... the channel of communication going away, misenterpretation, the agent or myself dying, the resources not being available or delays due to manufacturing may impede progress.

That is just the way the real world works.

Although Future/Promise can be built easily on top of Actor, they are optimistic at best - especially in diatributed cases; which, if my interpretation is correct is your reason for Actor in the first place.

Actor is powerful so in my opinion, future/promise and building ref-counts on top undermines the core of it.

Pat Helland, after numerous years of distributed transaction work completely did a 180 in the face of reality.

There is nothing wrong with Actor.

As far as strong typing, I personally believe that is a completely orthogonal conversation. I just cannot see the conflation.

Strongly typed to me means I send an argument to a function and it happens to match the signature.

Well, if I have a strongly typed function that takes two integers and somehow is supposed to return the sum. I guess it is helpful to know that as the user-agent (caller) of the function, but that knowledge only helps programmers, not computers.

Strong typing is definitely not a model of reality when dealing with humans as functions, and often humans are end-point "processes" (heh) of function calls.

Not that I am against strong typing in any way. I just believe the Actor model is cleaner without mixing things up.

Certainly agree Erlang is great but not the ultimate.

Well... my 2c and thanks to you, Alan, Joe, Hoare, Sussman, Gelernter et al. et al. for the inspirations over the years, and appreciate you plugging away at the models to this day.

Have a wonderful holiday.

Yes and no. Carl hewit will tell you that erlang's actor model is not pure (and to be sure a process doesn't have to be much of an actor - like Elixir's Task module). But I think that impurity is one of the strengths of the BEAM.

So I would qualify 'best' to meant "easiest system that 95% looks like actors that you can quickly get up and running and doing useful things and or play around with"

E (http://erights.org/), Monte (https://www.monte-language.org/), and Pony (https://www.ponylang.io/) are probably the most faithful actor-model languages I know of.

Above are important contributions, but they don't provide an adequate foundation for Actor massive concurrency.

Any others around today that do?

In erlang based systems stateful network protocols and concurrent user stories are all modeled with actors and one million connections per node for websockets is a thing.

I deployed an actor-based system model to completely rearchitect and replace an inefficient stateless python system. There have been zero runtime or concurrency errors since I deployed (unfortunately sometimes the hardware the actors are modeling fail us) but patches to work around the hardware failures are simple.

The Actor Model has been used in many important large applications [Bernstein, Bykov, Geller, Kliot, and Thelin 2014; Bonér and Reisz 2017, Cesarini 2019] and has become the foundation for current computing.

Satisfactory implementation for Reusable Scalable Intelligent Systems with millions of Actor cores for quadrillions of Actor are under development, but not yet publicly available.

I think so, I'm accidentally building an actor centric programming language and it is a magical way of building stuff.

I understand the accidental aspect. I've accidentally now written a spreadsheet while replacing a set of Makefiles with a more readable dependency graph of files. Now I'm adding a graphing component...

how do you handle persistence ? i’m trying to design a system at the moment and i feel like actors are great until you have to deal with persisting state to a database ( at which point the idea of having millions of independant process each hitting your database to save and load their state look like a disaster)

edit : i misread your post, thought you were designing a system, not a PL... maybe you can still answer my question ?

Actors should be inherently persistent unless no longer reachable.

What i mean by persistent is : what is the best practice to save an actor’s state so that it can be properly restored in case of a crash without loosing information.

I think i’m still not clear on how you would design a transactional system ( such as order & paiement processing ) with actors in a way that won’t make it look like a microservice based system ( aka : one per subtask, fetching info from a db for each incoming request, and storing the result in a db in the end)

It seemed to me actors had to have a more fine grained context ( such as one per order), but in that case i’m wondering how it’s supposed to handle saving its state regularely so that no information on the order processing state is ever lost

Excellent question! But your question seems to make the unfounded assumption that application programmers should be in charge of restoring crashed Actors. Instead, an Actor System should restore Actors as best it can based on recordings that it has. Applications must be made resilient against any and all kinds of inconsistencies that will pervasively arise.

Do you know any resource i could read that would explain how all that is supposed to work out in practice ?

I've never heard of an actor system able to automatically respawn actors with their previous state (the whole system would look like a tree of cached data, each layer responsible for saving the leafs under it, with a huge "persist to DB" on top , wouldn't it ?). Does erlang OTP do those kind of things ?

Edit: also, are you Prof "Carl" Hewitt ? The one that invented actors ? I'd be honored you found a question of mine about actors excellent...

This is what I am building. I'm building a database of actors that are free agents in a way.

The key insight is that an actor is a tiny VM and you just need to make the VM state durable.

I see many challenges :

- not all states transitions need to be durable. If performance matters you’ll have to get your actors to call something like a « saveState » from time to time, otherwise every single property change is going to have an overhead in terms of performance.

- what does « durable » mean ? Surely, just having the state of an actor saved in the memory of the supervisor isn’t enough. If the two are on the same server and the server shuts down, it’s game over. You need a « persistence » service / actor, but that thing is going to have to persist the state of all the actors in your system. I don’t see how that can work if you’ve got millions of actors running in parallel.

Durability is a matter of degree. Lowest is to record in RAM. Next is persistent local storage. After that comes storage on other machines.

That's not how you would persist to the database. Processes (Erlang VM threads) have mailboxes that process messages (like records to be saved to db) in a queue. Everything is built around message passing, each process just handles its own narrow job.

You should check how Erlang / Elixir database drivers handle that.

In my experience with Elixir there are never many processes that have a state to save in a database. Eventually it's the same load no matter if the implementation is actor based or object oriented.

but then how do you deal with transactionnal behaviors ?

Check Elixir's Ecto module https://hexdocs.pm/ecto/Ecto.html

The general idea is to build the transaction in a pipeline of function calls. Each function gets the old definition of the transaction as an argument and returns a new one. Eventually the call at the end of the pipeline executes the statements in the definition, wrapping them in a transaction.

If the question is how to deal with 100 or 100 k concurrent transactions, the answer again is in the same way a cluster of servers running programs written in any other language do. Eventually SQL is SQL.

I'm building my own database-like thing

Actors keep getting rediscovered because they are universal abstraction for digital computation.

My nightmare scenario is that Larry Ellison rediscovers the Oracle Turing Machine, and copyrights its API.

https://en.wikipedia.org/wiki/Oracle_machine

https://arstechnica.com/tech-policy/2019/11/supreme-court-wi...

(In the cover photo of that article, it looks like people have been urinating on the Oracle logo!)

I believe it, and I think we are in this stage of figuring out which model to represent it make the most sense in a broader scope.