4 ms·

What are the advantages and disadvantages vs using Actix or Ractor?

by m00x 2y ago

deleted 2y ago
[deleted]
mtndew4brkfst 2y ago
PSA: Actix (not Actix-web) is fairly inactive - one of the maintainers informally said not to use it for any new projects during one of this year's RustConf chats.
- snowboarder63 2y ago
  https://discord.com/channels/734893811884621927/1270439672627331202/1283493019403681814 https://discord.com/channels/734893811884621927/127043967262...
stusmall 2y ago
The actix crate is deprecated. I looked on their site and repo and couldn't find an official announcement of deprecation but here is a link to what the lead said when I reached out with questions a few months ago: https://discord.com/channels/771444961383153695/771447523956883466/1204823567452217365 https://discord.com/channels/771444961383153695/771447523956... EDIT: Tangent, but if anyone has experience making deterministic actor model systems that can be run under a property test I'd love to know more. It would make an amazing blog post even if it would have a very narrow audience
status_quo69 2y ago
I actually went through this exact exercise recently, but this library didn't show up in my searches for a good rust actor framework, so take that with a grain of salt. It looks very similar to the interface provided by actix at first blush, not sure how supervision works. My take is that most of these frameworks tend to solve with the same(ish) solution, so pick the one that has the best api. I liked ractor, although not having &mut self eventually wore me down. I swapped a small side project to use Stakker instead and while at first the macros intimidated me, the implementation really impressed me in terms of performance and API characteristics. It really feels like there's just enough there and no more.
tqwewe 2y ago
Actix was built initially using its own runtime and has gone over many iterations including a runtime change to tokio over its lifetime. In the past, building asynchronous actors with actix has been a huge pain and felt like a big after thought. 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 2y ago
  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 with native future returns https://github.com/slawlor/ractor/pull/202 https://github.com/slawlor/ractor/pull/202 (For transparency I'm the author of ractor)
  - snowboarder63 2y ago
    Also ractor is used in production at Meta. (Which I can finally say publicly lol) Here's the RustConf presentation for anyone interested https://slawlor.github.io/ractor/assets/rustconf2024_presentation.pdf https://slawlor.github.io/ractor/assets/rustconf2024_present...

What are the advantages and disadvantages vs using Actix or Ractor?

by m00x 2y ago

What are the advantages and disadvantages vs using Actix or Ractor?

deleted 2y ago

[deleted]

mtndew4brkfst 2y ago

PSA: Actix (not Actix-web) is fairly inactive - one of the maintainers informally said not to use it for any new projects during one of this year's RustConf chats.

snowboarder63 2y ago
https://discord.com/channels/734893811884621927/1270439672627331202/1283493019403681814 https://discord.com/channels/734893811884621927/127043967262...

stusmall 2y ago

The actix crate is deprecated. I looked on their site and repo and couldn't find an official announcement of deprecation but here is a link to what the lead said when I reached out with questions a few months ago: https://discord.com/channels/771444961383153695/771447523956883466/1204823567452217365 https://discord.com/channels/771444961383153695/771447523956... EDIT: Tangent, but if anyone has experience making deterministic actor model systems that can be run under a property test I'd love to know more. It would make an amazing blog post even if it would have a very narrow audience

status_quo69 2y ago

I actually went through this exact exercise recently, but this library didn't show up in my searches for a good rust actor framework, so take that with a grain of salt. It looks very similar to the interface provided by actix at first blush, not sure how supervision works. My take is that most of these frameworks tend to solve with the same(ish) solution, so pick the one that has the best api. I liked ractor, although not having &mut self eventually wore me down. I swapped a small side project to use Stakker instead and while at first the macros intimidated me, the implementation really impressed me in terms of performance and API characteristics. It really feels like there's just enough there and no more.

tqwewe 2y ago

Actix was built initially using its own runtime and has gone over many iterations including a runtime change to tokio over its lifetime. In the past, building asynchronous actors with actix has been a huge pain and felt like a big after thought. 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 2y ago
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 with native future returns https://github.com/slawlor/ractor/pull/202 https://github.com/slawlor/ractor/pull/202 (For transparency I'm the author of ractor)
- snowboarder63 2y ago
  Also ractor is used in production at Meta. (Which I can finally say publicly lol) Here's the RustConf presentation for anyone interested https://slawlor.github.io/ractor/assets/rustconf2024_presentation.pdf https://slawlor.github.io/ractor/assets/rustconf2024_present...