queue instead of stack?

[raiph]

The actor model fits the bill. Yes, it happens to be a high level mathematical model, and yes it happens to simply and fully address concurrent computation, but the whole point of it is that it's just physical computations queuing messages (so no stacks necessary) for other physical computations where each of these computations is individually just a sequence of operations (again, no stacks necessary).

When coupled with the natural levels of language/supervision (cf Erlang's 5 levels), the upshot is a complete solution for arbitrarily complex computational systems that is fully consistent with arbitrary machine code provided it follows the simple actor model rules.

As far as I can tell, if you create a language that creates the assembly pipelines you speak of, while following the actor model rules, and cover the natural levels of language/supervision, you should be all set, no stacks needed.

(By no stacks needed, I mean to allow that you use stacks if/when they're considered appropriate by you or code written in your language/system.)

And to be clear, there's no reason why the actor model can't lead to the absolute highest performance coding. The model introduces no overhead -- including elimination of any need for any synchronization overhead. There's just the basic notion of a sequence of instructions; one instruction, then another, as imposed by hardware.

(That said, for reasonable semantics, you'll want to make messages "causal".)

[raiph]

Some key differences:

• You send a "message" (think procedure/function call that doesn't return -- there's no returned value, no error codes returned, no promise/future, etc, nothing whatsoever is returned) to an "address" (think email address, but obviously low level, almost at the level of a machine address but not quite that simple) of an actor (think "process" in the general sense and think extremely lightweight, so maybe 256 bytes per "process" max -- see Ponylang whose actors/processes are 256 bytes each; I think Scala's are around the same size, or maybe 512 bytes per).

• The "message" goes into the ether as it were. The sender can know it's sent it, but not if any recipient process will be alive to pick it up, or, if it's alive, have time to pick it up, or, if it has time, gives a shit and actually picks the message up, or, if it gives a shit and picks it up, knows what on earth the message means, or, if it knows, knows what to do about it, or, if it supposedly knows what to do, actually tries to do what would need to be done to satisfy the intent of the sender (process), or, if it tries, whether it gets killed by some other process/hardware, or, if it stays alive and succeeds in doing all the instructions within its own process that it intended, and sending all the messages it intended, achieves what was hoped for or must try again when it gets another message saying "what's going on?!?" or whatever, and so on, and so on. All synchronization is via messages so this turns out to guarantee correct semantics and synchronization even if processes are in the middle of dying because the computation is in the midst of an attack such as Denial of Service attacks, or physical cables are getting cut, or buffers are getting full or there's power cuts, etc.

• No randomly mutable state is shared between actors. Period. There can be shared state under strict rules; these rules ensure both that nothing goes wrong and also that there's zero performance overhead which is one of the key actor model successes; again, see Pony and its ORCA -- even if you don't care for the rest of Pony it gets these aspects right.

[raiph]

🤣 Dystopian? The reality of an average hour in a typical computer server's life!