ractor

After a little confusion I see this "Ractor" is the Ruby actors library https://ruby-doc.org/3.2.2/Ractor.html I was a little confused because when I think of Ractor, it's the Rust "Ractor" library https://github.com/slawlor/ractor which is an awesome library that brings Erlang/OTP gen_server actors to Rust and is very clean. Worth checking out BTW if you use Rust.

From the README (https://github.com/slawlor/ractor?tab=readme-ov-file#differe...): > When designing ractor, we made the explicit decision to make a separate state type for an actor, rather than passing around a mutable self reference. The reason for this is that if we were to use a &mut self reference, creation + instantiation of the Self struct would be outside of the actor's specification (i.e. not in pre_start) and the safety it gives would be potentially lost, causing potential crashes in the caller when it maybe shouldn't. > Lastly is that we would need to change some of the ownership properties that ractor is currently based on to pass an owned self in each call, returning a Self reference which seems clunky in this context.

While the state is indeed a separate struct in ractor there's actually a good reason for this. It's because the state is constructed by the actor and it's guaranteed that the construction is the state is managed by the startup flow and panic safe. Imagine opening a socket, if you have a mutable self the caller who is going to spawn that actor needs to open the socket themselves and risk the failure there. Instead of the actor who would eventually be responsible for said socket. This is outlined in our docs the motivation for this. Essentially the actor is responsible for creation of their state and any risks associated with that. - for the async trait point we actually do support the native async traits without the boxing magic macro. It's a feature you can disable if you so wish but it impacts factories since you can't then box traits wi

This project also appears interesting, but it seems that its clustering features have yet to be tested in large scale distributed systems. https://github.com/slawlor/ractor/discussions/131

I’ve liked using ractor. https://github.com/slawlor/ractor

If you look at my comment history, you'll see I'm well familiar with the BEAM. I'm in full agreement with you, but I'm not sure you need full robust process supervision trees to mimic what the BEAM does in the context of LiveView on a single machine. I do want to say, I 100000% times prefer Elixir, it's tooling, ecosystem, web frameworks, easy of scaling vertically and horizontally, etc over Go or any other lang that probably do something analogous to LiveView via what ever concurrency primitives that language/runtime champions; Go with it's Communicating sequential processes(CSP) and Rust with the Ractor lib (https://github.com/slawlor/ractor).

SOME HIGHLIGHTS. * We have a full supervision tree so actors can monitor other actors for exits and unhandled panic!s (at least the ones that can be caught) * The actor lifecycle is handled for you in a simple single-threaded, message handler primitive * You have a mutable state with each message handling call, so you have an easy way to create stateful actors and update that state as messages are processed * Actors talk to other actors by message passing, but there are remote-procedure-calls (RPCs) so actors can "ask a question" to another actor and wait on the reply. * A lot of the concurrency primitives are handled by the framework, such as cancellation/termination of actors (both graceful and forceful) * A Factory primitive in order to formulate distributed processing pools with multiple job routing options * Early but stable support