I think what's missing is that this an extremely low level programming model:
Upon receipt of this message in the event E, the target consults its script (the actor analogue of program text), and using its current local state and the message as parameters, sends new messages to other actors and computes a new local state for itself.
It doesn't say anything about whether you do:
- nginx-style state machines in C
- callbacks in C++, or C++ 20 coroutines
- async/await in Rust
- Goroutines in Go
- async/await in Python or JS, with garbage collection
etc. I don't think the "actor model" really means that much these days.
What's a "canonical" and successful actor model program? What can we learn from such programs?
I think if you ask 5 people you'll get 5 different answers.
---
Also, with
__u8 opcode; /* type of operation for this sqe */
__s32 fd; /* file descriptor to do IO on */
then you have lost all static typing. It is too low level, so the analogy doesn't really hold up IMO.
Also, I don't understand why it's "do files want to be actors?", not "do Unix PROCESSES want to be actors?"
Which is why when you have programming languages with rich runtimes and ecosystem, the OS kind of becomes irrelevant.
"an operating system is a collection of things that don't fit inside a language; there shouldn't be one"
-- Dan Ingalls
So what happens is that those runtimes built on top of whatever low level primitives are available, and that is about it.
Even considering UNIX alone, many ways to do asynchronous IO aren't even part of POSIX, it has remained specific to each UNIX flavour.
To some extent, UNIX/POSIX API surface has been the C and C++ standard library that WG14 and WG21 didn't want to take over into ISO, but almost every C and C++ developer expects to exist anyway.
Upon receipt of this message in the event E, the target consults its script (the actor analogue of program text), and using its current local state and the message as parameters, sends new messages to other actors and computes a new local state for itself.
It doesn't say anything about whether you do:
etc. I don't think the "actor model" really means that much these days.What's a "canonical" and successful actor model program? What can we learn from such programs?
I think if you ask 5 people you'll get 5 different answers.
---
Also, with
then you have lost all static typing. It is too low level, so the analogy doesn't really hold up IMO.Also, I don't understand why it's "do files want to be actors?", not "do Unix PROCESSES want to be actors?"
(copy of lobste.rs comment)