(no title)
tqwewe | 1 year ago
Ractor is nice, and I've used it in the past. A couple things differ between kameo and ractor:
- In ractor, messages must be defined in a single enum – in kameo, they can be separate structs each with their own `Message` implementation. This means messages can be implemented for multiple actors which can be quite useful.
- In ractor, the actor itself is not the state, meaning you must typically define two types per actor – in kameo, the actor itself is the state, which in my opinion simplifies things. As someone mentioned in a comment here, it was a bit of a turn off for me using ractor in the past and I didn't fully agree with this design decision
- Ractor requires the `#[async_trait]` macro – kameo does not.
There may be other obvious differences but I'm not super familiar with ractor besides these points
snowboarder63|1 year ago
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 with native future returns https://github.com/slawlor/ractor/pull/202
(For transparency I'm the author of ractor)
tqwewe|1 year ago
I wasn't aware async_trait wasn't needed, thats nice to see.
Also congrats on it being used in such a big company, thats awesome! I have a lot of respect for ractor and appreciate your response
snowboarder63|1 year ago
Here's the RustConf presentation for anyone interested https://slawlor.github.io/ractor/assets/rustconf2024_present...