Thoughts About the Actor Model

2025-09-24

The Actor model looks reasonable, but, I have been wary of implementations I’ve seen as being too synchronous and based on shared memory.

I believe that dynamic connections will lead to hard-to-debug bugs. The electronics schematic idea of having inter-component wires hard-wired into a design by hardware engineers is better than the self-modifying code potential of dynamic connections.

As far as I remember, the Actor model does not specify anything but an infinite canvas of actors, which means that we need a “GOTO Considered Harmful” revelation for async Parts.

I think that business ORG charts are an interesting model for architecting scalable systems

• hierarchical tree (not graph or DAG)

• layers of middle management

• requests flowing downwards

• summaries flowing upwards

• no direct peer-to-peer communication

• no going over the boss’s head

• no micro-management

• etc.

A lot of early computing was overly-influenced by co$t considerations and the strict sequential nature of CPU opcode interpretation

• time-sharing CPUs instead of using 1,000s of CPUs

• memory-sharing instead of message-passing

• Gutenberg type-setting

• belief in the functional model (all parameters arrive at once, all results routed back to the caller).

Using today’s hardware, we can replace these biases with ideas like:

• 1,000s of CPUs where each CPU contains essentially-single-threaded code

• Message-passing over thin-bandwidth wires

• Program syntaxes with overlappable elements not arranged in strict grids

• Diagrams as Syntax (DaS)

• Notations that allow easier reasoning-about time latencies

• Allowing a wider latitude of routing policies (instead of the strict “return-to-caller” routing policy)

• Multiple inputs

• Multiple outputs

• The ability to send zero or more messages per reaction, kept in order of arrival/generation along with the ability to reason-about sequencing and order

• Richer program development environments that allow plumbing together of multiple paradigms and multiple languages for program creation.

It’s been a looong time since I looked closely at the Actor model. Maybe I should revisit it with fresh eyes to see if it agrees with my biases or to remember what I thought is insufficient.

In my mind the electronics-schematic model (e.g. TTL) is a hint of how to architect systems that contain massive parallelism, whereas the functional model is a way to architect the innards of single nodes in massively parallel systems. ICs are little black boxes (often actually black in colour) with very well-defined interfaces to the outside world (“pins”). Harel’s Statecharts paper is an interesting hint, too. We learned in kindergarten about “not colouring outside the lines” (scope, containment, isolation). All need further improvement.

See Also

Email: ptcomputingsimplicity@gmail.com

Substack: paultarvydas.substack.com

Videos: https://www.youtube.com/@programmingsimplicity2980

Discord: https://discord.gg/65YZUh6Jpq

Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas

Twitter: @paul_tarvydas

Bluesky: @paultarvydas.bsky.social

Mastodon: @paultarvydas

(earlier) Blog: guitarvydas.github.io

References: https://guitarvydas.github.io/2024/01/06/References.html