3 ms·

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 a

by evnix 4y ago

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.

dmitriid 4y ago
> 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.
imtringued 4y ago
That isn't actually true. 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.
Dowwie 4y ago
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.

by evnix 4y ago

dmitriid 4y ago

> 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.

imtringued 4y ago

That isn't actually true. 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.

Dowwie 4y ago

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.