4 ms·
I would spend some time experimenting with Erlang or Elixir. The thing that really made the actor model "click" for me was how each actor in Erlang is just a pr
by bitwalker 9y ago
I would spend some time experimenting with Erlang or Elixir. The thing that really made the actor model "click" for me was how each actor in Erlang is just a process (green thread basically). The only way to communicate between processes/actors is message passing, and the way you end up constructing software is by modeling individual tasks and responsibilities of your application in terms of processes. The way processes are constructed in Erlang/Elixir allow you to pattern match on messages to selectively receive or prioritize messages, and discard others. A process can be written in such a way that it changes from one role to another just by being sent a message, or from one state to another (in the case of finite state machines and the like).
A typical example of how it gets applied might be a web server, where each HTTP request is handled by its own process, and potentially delegating multiple tasks concurrently to other processes in the background which handle queuing and executing work associated with that request. You might have pipelines of processes, each responsible for some specific task/transformation before handing off work to the next stage in the pipeline. On top of that Erlang/Elixir provide supervision, where components of the system are started/monitored by a special process type called a supervisor, which will restart its children when failure occurs, and if a set of conditions fail, will itself be restarted by its parent supervisor. So your application ends up structured as a tree of supervisors and worker processes, where components of the application are branches of the tree, and can be isolated from the failure of other components.
Hopefully that helps give you an idea of how the model plays out in practice. I would definitely recommend playing around with either Erlang or Elixir, they are a lot of fun, and it really changes the way you think - at least it did for me.
- napsterbr 9y agoHey, off topic but I have to say this, we use a bunch of libraries authored / maintained by you. Thanks!
- fpoling 9y agoWhy it is necessary to discard messages? Isn't it a sign of bad design when resources have to be spend to create and pass a message that is ultimately discarded?
- ramchip 9y agoI think it’s just a bit badly worded. You don’t normally throw them away, you leave them in the queue for later. For instance if you have a process that gets requests and writes stuff to DB, while processing a request you can send a message to the DB, then use a selective receive to match on the response from the DB while ignoring all other messages (you’ll deal with them later i.e. when you fetch the next request to process).
- spiralx 9y agoProcesses discard messages that they aren't interested in, that doesn't mean another process isn't.
- fpoling 9y agoErlang has one message queue per prosess. So if a process discards the message, the message cannot be available for other processes. Moreover, as Erlang does not have message broadcast and all messages the process receives were explicitly sent to it, the process can not receive messages accidentally.