5 ms·

I think so, I'm accidentally building an actor centric programming language and it is a magical way of building stuff.

bsaul 7y ago
how do you handle persistence ? i’m trying to design a system at the moment and i feel like actors are great until you have to deal with persisting state to a database ( at which point the idea of having millions of independant process each hitting your database to save and load their state look like a disaster) edit : i misread your post, thought you were designing a system, not a PL... maybe you can still answer my question ?
- pmontra 7y ago
  You should check how Erlang / Elixir database drivers handle that. 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.
  - bsaul 7y ago
    but then how do you deal with transactionnal behaviors ?
    - pmontra 7y ago
      Check Elixir's Ecto module https://hexdocs.pm/ecto/Ecto.html https://hexdocs.pm/ecto/Ecto.html 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.
- verttii 7y ago
  That's not how you would persist to the database. Processes (Erlang VM threads) have mailboxes that process messages (like records to be saved to db) in a queue. Everything is built around message passing, each process just handles its own narrow job.
- mathgladiator 7y ago
  I'm building my own database-like thing
- ProfHewitt 7y ago
  Actors should be inherently persistent unless no longer reachable.
  - bsaul 7y ago
    What i mean by persistent is : what is the best practice to save an actor’s state so that it can be properly restored in case of a crash without loosing information. 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
    - ProfHewitt 7y ago
      Excellent question! But your question seems to make the unfounded assumption that application programmers should be in charge of restoring crashed Actors. Instead, an Actor System should restore Actors as best it can based on recordings that it has. Applications must be made resilient against any and all kinds of inconsistencies that will pervasively arise.
      - bsaul 7y ago
        Do you know any resource i could read that would explain how all that is supposed to work out in practice ? 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...
        mathgladiator 7y ago
rs23296008n1 7y ago
I understand the accidental aspect. I've accidentally now written a spreadsheet while replacing a set of Makefiles with a more readable dependency graph of files. Now I'm adding a graphing component...
ProfHewitt 7y ago
Actors keep getting rediscovered because they are universal abstraction for digital computation.
- DonHopkins 7y ago
  My nightmare scenario is that Larry Ellison rediscovers the Oracle Turing Machine, and copyrights its API. https://en.wikipedia.org/wiki/Oracle_machine https://en.wikipedia.org/wiki/Oracle_machine https://arstechnica.com/tech-policy/2019/11/supreme-court-will-review-high-stakes-google-v-oracle-ruling/ https://arstechnica.com/tech-policy/2019/11/supreme-court-wi... (In the cover photo of that article, it looks like people have been urinating on the Oracle logo!)
- mathgladiator 7y ago
  I believe it, and I think we are in this stage of figuring out which model to represent it make the most sense in a broader scope.

how do you handle persistence ? i’m trying to design a system at the moment and i feel like actors are great until you have to deal with persisting state to a database ( at which point the idea of having millions of independant process each hitting your database to save and load their state look like a disaster) edit : i misread your post, thought you were designing a system, not a PL... maybe you can still answer my question ?

pmontra 7y ago
You should check how Erlang / Elixir database drivers handle that. 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.
- bsaul 7y ago
  but then how do you deal with transactionnal behaviors ?
  - pmontra 7y ago
    Check Elixir's Ecto module https://hexdocs.pm/ecto/Ecto.html https://hexdocs.pm/ecto/Ecto.html 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.
verttii 7y ago
That's not how you would persist to the database. Processes (Erlang VM threads) have mailboxes that process messages (like records to be saved to db) in a queue. Everything is built around message passing, each process just handles its own narrow job.
mathgladiator 7y ago
I'm building my own database-like thing
ProfHewitt 7y ago
Actors should be inherently persistent unless no longer reachable.
- bsaul 7y ago
  What i mean by persistent is : what is the best practice to save an actor’s state so that it can be properly restored in case of a crash without loosing information. 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
  - ProfHewitt 7y ago
    Excellent question! But your question seems to make the unfounded assumption that application programmers should be in charge of restoring crashed Actors. Instead, an Actor System should restore Actors as best it can based on recordings that it has. Applications must be made resilient against any and all kinds of inconsistencies that will pervasively arise.
    - bsaul 7y ago
      Do you know any resource i could read that would explain how all that is supposed to work out in practice ? 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...
      - mathgladiator 7y ago

rs23296008n1 7y ago

I understand the accidental aspect. I've accidentally now written a spreadsheet while replacing a set of Makefiles with a more readable dependency graph of files. Now I'm adding a graphing component...

ProfHewitt 7y ago

Actors keep getting rediscovered because they are universal abstraction for digital computation.

DonHopkins 7y ago
My nightmare scenario is that Larry Ellison rediscovers the Oracle Turing Machine, and copyrights its API. https://en.wikipedia.org/wiki/Oracle_machine https://en.wikipedia.org/wiki/Oracle_machine https://arstechnica.com/tech-policy/2019/11/supreme-court-will-review-high-stakes-google-v-oracle-ruling/ https://arstechnica.com/tech-policy/2019/11/supreme-court-wi... (In the cover photo of that article, it looks like people have been urinating on the Oracle logo!)
mathgladiator 7y ago
I believe it, and I think we are in this stage of figuring out which model to represent it make the most sense in a broader scope.