A lot of progress has been made since I last submitted this project, back in 2019: https://news.ycombinator.com/item?id=21796753

- Remoting

- Clustering

- Sharding

- Persistence (redis connector & in-memory currently provided, more to come)

- Supervision

- Metrics

- Tracing

- Service Discovery (+ k8s)

And much more! :)

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

Thoughts on Tower? The Handler impl seems similar.

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.

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.

"Show HN: Ractor – a Rust-based actor framework with clusters and supervisors" (2 days ago):

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.

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.

Within the rust ecosystem, rust has tokio as a clear winner for async runtime without a top-down mandate.

There are a couple of alternatives, but none of them come close in popularity

Akka seemed to win in Scala

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.

Let me know if you want to chat!

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.

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.

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