The thing that makes Erlang and its actor framework great is pre-emption. you basically write code without having to worry about the colour of the function or about tight loops. you write simple synchronous code and the framework takes care when to preempt, be it I/O or CPU instructions.
I really wish most new actor frameworks weren't just a replacement for an async library+rabbitmq.
> The thing that makes Erlang and its actor framework great is pre-emption.
That's one side of the coin. The other side is that the VM all but guarantees that a crash in a process will not bring the VM down and that you can get a notification that the process died.
The primary benefit of the actor model is isolating/encapsulating resources and providing a safe interface to access them.
If you take an object in OOP and just throw locks around every single method you will be in a world of pain because you not only have to worry about potential resource leakage slipping past the lock, you also have to worry about the fact that you have now mixed up both the concurrent and internal non concurrent interface into one thing. If one of your synchronized public methods calls another public synchronized methods then you straight up run into a deadlock. So now you have to create an extra synchronized wrapper class that either conforms to the interface or works more like a Rust Mutex where you have to acquire the lock before you can access it's contents.
In an actor model both isolation and concurrent interface come out of the box out of the architecture. Pre-emption is just a cherry on top. If Java gets loom (green threads) then the actor library can just migrate to that with immediate performance benefits.
That hasn't been my experience with Elixir. I have a lot of options and a lot of decisions to make about concurrency. Do I want this task to return a response later and do something with it? Do I want the task to die if the parent task dies? Do I want to decouple the lifetimes of parent and child? How do I handle the response received later? However, once these decisions are made, it is a straightforward process to integrate the desired functionality.
But then the main contributor, Lightbend company, decided to change the license from Apache 2, to BSL.. Now Apache Pekko is the fork that should continue the implementation :)
There's a class of software project where it isn't very hard to bash together a simple thing that solves a good chunk of the problem, not covered by the language itself, but has endless elaborations you can put on them.
These rarely stabilize in the sense you mean, of there being exactly one sensible choice in some domain. (Note difference between "rarely" and "never".)
See also: Web framework, Javascript GUI framework, serialization libraries (easy to write the parser(s), endless combinations of ways to handle the resulting JSON for you), and these are just some big frequent examples that leap to mind. There's a lot of these sorts of things.
This is cool, I’ve been working on something similar in Go: https://github.com/richardartoul/nola but with a slightly different focus on linearizability / durability and Webassembly.
I always have mixed feeling about having mut self in the handler. On one end its nice to avoid locking the inner state, but it does prevent processing of messages concurrently. This is annoying in many cases where you want for example a central state bound to an IO call.
I really want to use rust for some new projects. But 98% of the pins out there are great v.5s, it’s tough to bet your future on a v.5. Where are the “why aren’t you using rust for this? Use cases.”
18 comments
[ 7.2 ms ] story [ 71.4 ms ] thread- Remoting
- Clustering
- Sharding
- Persistence (redis connector & in-memory currently provided, more to come)
- Supervision
- Metrics
- Tracing
- Service Discovery (+ k8s)
And much more! :)
I really wish most new actor frameworks weren't just a replacement for an async library+rabbitmq.
That's one side of the coin. The other side is that the VM all but guarantees that a crash in a process will not bring the VM down and that you can get a notification that the process died.
The primary benefit of the actor model is isolating/encapsulating resources and providing a safe interface to access them.
If you take an object in OOP and just throw locks around every single method you will be in a world of pain because you not only have to worry about potential resource leakage slipping past the lock, you also have to worry about the fact that you have now mixed up both the concurrent and internal non concurrent interface into one thing. If one of your synchronized public methods calls another public synchronized methods then you straight up run into a deadlock. So now you have to create an extra synchronized wrapper class that either conforms to the interface or works more like a Rust Mutex where you have to acquire the lock before you can access it's contents.
In an actor model both isolation and concurrent interface come out of the box out of the architecture. Pre-emption is just a cherry on top. If Java gets loom (green threads) then the actor library can just migrate to that with immediate performance benefits.
https://news.ycombinator.com/item?id=34813489
It feels like async / actor frameworks / gui things are permanently in flux. I wish clear winners would emerge already.
In OSS ecosystems it's usually plenty of choices, or nothing.
See NPM registry or choosing DE in Linux.
There are a couple of alternatives, but none of them come close in popularity
These rarely stabilize in the sense you mean, of there being exactly one sensible choice in some domain. (Note difference between "rarely" and "never".)
See also: Web framework, Javascript GUI framework, serialization libraries (easy to write the parser(s), endless combinations of ways to handle the resulting JSON for you), and these are just some big frequent examples that leap to mind. There's a lot of these sorts of things.
Let me know if you want to chat!