"actors" forward in readme

[goodboy]

I think to prevent having to rehash/explain actor theory each time we get new onlookers there should be a quick rant in the readme under the hood section regarding what the literature, videos, and thus theory author's have to say about what constitutes being an actor model implementation.

This is obviously directly related to #18 which is of course for further involved discourse / research / interpretations of the theory.

The main issue I think we're finding is a lot of onlookers tend to have misconceptions about actor model theory mostly pertaining to this notion that actors are somehow realized as some kind of specific API or type system semantics; this is simply not true.

an "actor model" is a conceptual, computational model; it is specifically not strict about the limitations of an implementation of the system at hand. In fact, arguably most interpretations of the concepts which try to literally implement (usually with the same names) the distinguishing (abstract) elements from the model (eg. messages, ether, everything is an actor, strictly un-buffered channels, mailboxes) are simply misguided and not in line with original authors' intent.

Here are the true and minimal set of caveats:

• the actor model came about specifically to cope with a controversial theory that proposes that unbounded non-determinism can exist in real systems.

  • the actor model is proposed as a solution to deal with UND
  • prior systems that didn't address this theoretical issue eventually did adjust their formalities to include UND as a property:

  These early models by Milner and Hoare both had the property of bounded nondeterminism. Modern, theoretical CSP ([Hoare 1985] and [Roscoe 2005]) explicitly provides unbounded nondeterminism.

• the only absolute strict requirements for an implementation to be considered an "actor model" are that it must adhere to the 3 axioms:

  • An actor is a computational entity that, in response to a message it receives, can concurrently:

    • send a finite number of messages to other actors;
    • create a finite number of new actors;
    • designate the behavior to be used for the next message it receives.
  • if you don't adhere to these then you aren't an actor model

• this can be verified explicitly by Hewitt saying it plain and simple at this point, in this video

• concepts from the actor model are more often mapped onto existing systems which can address the issue of UND as opposed to taking the concepts and trying to implement subjective author-perceived semantics literally; this is not what the original author proposes.

Since tractor does in fact have the ability to cope with UND (as far as we can tell), and it can suffice the 3 axioms, there is no reason it is not an actor model. We're of course willing to be proven wrong.

My hope is we can quell confusion and misconceptions about all of this from the outset so that we can move on with adding more features to the project without getting caught up with superfluous "actor model concept forced semantics mappings" that don't fit with the idiomatics of python and trio style structured concurrency.

I will say this again, we are not trying to look like what you think an actor model is supposed to look like.
Why?
Maybe you didn't grok the argument presented in the paragraph above?

Assertion: most new onlookers likely have no clue why they think that "actor model" things should look a certain way in the first place; they haven't read the canon literature.

[goodboy]

This set of blog posts IMO further cements the above claim.

• http://www.dalnefre.com/wp/2010/05/deconstructing-the-actor-model/
• http://www.dalnefre.com/wp/2020/01/requirements-for-an-actor-programming-language/
• http://www.dalnefre.com/wp/2014/03/actors-in-javascript/

Python is not an actor programming language, thus trying to force actor types onto it doesn't necessarily accomplish anything. What's important is whether tractor as a runtime system adheres to the axioms and can demonstrate the necessary minimal functionality:

each actor can,

• create a new actor -> accomplished through our Python process spawning system
• send a message to an existing actor -> supported by our IPC and message transport system
• designate a new behavior for the current actor -> realized as trio scheduled tasks (coroutines) which can be suspended and resumed depending on what message next arrives to the process over the transport layer

I'm fairly confident most advanced concurrency people can map the ideas / requirements from that post to functionality in tractor. If there is still ongoing disbelief we can possibly write up a thorough walk-through in the docs to present the cases explicitly.

[goodboy]

Another entertaining example of non-actors in pop culture:
https://www.infoq.com/news/2021/06/swift-async-await-actors/

Oh boi, even more material:

• https://www.swiftbysundell.com/articles/swift-actors/
• https://www.swift.org/blog/distributed-actors/
• https://docs.swift.org/swift-book/LanguageGuide/Concurrency.html
• https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md
• https://forums.swift.org/t/concurrency-actors-actor-isolation/41613

Can anyone point out what's wrong here?
Hint: how about missing all 3 axioms of the model 🤔