Hacker News Reader

> Actor supervision systems (in whatever language) are essentially narcisstic: they have to be in control over the state management lifecycle

I'm not sure why you think elixir discourages using databases. Phoenix by default ships with ecto bindings and you're encouraged to use postgres or Amazon rds or whatever for your bulk state management. Phoenix pubsub ships with redis bindings as an option if you'd rather not use distributed erlang.

Fwiw, I have written a multinode graphql query handler that pulls results from actors instead of a database (in this case using a database as a central source of truth is a bad idea because the data being queried lives in "its own databases", libvirt, if you are curious, distributed across nodes and having competing sources of truth can be very hard to manage). Handling these queries was not difficult. And your actors, btw, don't typically live in a very deep hierarchy anyways, you use something like Registry, which lets you query your actors in a flat fashion (the only hierarchical components are supervisors, which don't store much in the way of business logic state)

I think the belief is that if all your state is held in a transactional database, then your actors don't have any state in them and at that point it's not clear what they're doing with messages that the sender couldn't just do directly themselves by talking to the database.

My own experience with Akka style actor designs has been pretty poor. The problem is you lose the notion of a cross-machine call stack. Actors just have mailboxes and process inbound messages/outbound messages, which means you have to maintain state machines yourself and/or handle re-entrancy. Lots and lots of bugs in designs like that.

On the other hand, simply doing blocking RPCs across services where the RPC framework handles re-entrancy and stack consistency for you, it doesn't have that issue. That's how services like Google search are built. They shard across many machines vs talking to a database directly primarily for performance or to enforce team boundaries, not as part of an over-arching architectural design pattern.

Yeah probably 90% of actors in elixir hold state that is relevant to a connection status. Think, tcp state machine or http connection state. It is veeery nice to have a state machine back your inbound http long poll or websockets connections if you want to do serverside rendering or serverside content streaming etc.

The other case is when you're doing something cqrs-ey where you can have competing load balances requests and you need to make sure that writes are logged, committed, then executed, and reads are cached. You should use an actor for that but ultimately your data will reside in a database.

This is totally different from systems that scale, where any application "state" is just transient from a request or message in order to facilitate a mutation in a dedicated store outside of the app.

It's notable that this is the model on which the world is built. This is the model that runs almost all the biggest systems in the world.

Please tell me if I am wrong, but I get the feeling that you conflate the idea of "bad programming and design of a system" with the actor model in general.

You can do just as badly with an object oriented model as you can with the actor model. Bad applications will be bad.