edit : i misread your post, thought you were designing a system, not a PL... maybe you can still answer my question ?
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
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...
The key insight is that an actor is a tiny VM and you just need to make the VM state durable.
- 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.
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.
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.