Show HN: Coerce – Distributed actor framework in Rust

It's a great project compared to others that just needs more visibility. Thank you for making it. :)

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

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.

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.

Without a top down mandate, what else can you expect?

In OSS ecosystems it's usually plenty of choices, or nothing.

See NPM registry or choosing DE in Linux.

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.

Isn’t part of the model that you only process one message at a time?

That's odd, why do you want to process message concurrently, the entire point of actor is processing one message at a time deterministically.