You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unfortunately I discovered on their discord last night that Actix is going to be deprecated in a few months. The recommendation the Actix team have been suggesting is to follow the patterns within this excellent post on how to use tokio to create actors another possibility would be to use ractor I think there are tradeoffs for both approaches.
Actix itself was written before async or tokio was a thing in Rust and it has been playing catch up despite being eventually built with it. Since then Tokio actually provides some good async channel primitives we can use which Actix defined itself.
This opens up opportunities to fix some of the annoying things about Actix:
Lack of simple async compatibility
Lack of hierarchical supervision
Unified state persistence story for actors
We don't really need all the features of the Actix framework anyway.
Makes it easier to share our Actor model throughout our codebase
We can simply use the broadcast channel from tokio to setup the eventbus.
We would want to attempt to avoid using too much boilerplate in our adoption of the Actor model although it requires a fair amount of generic gymnastics to avoid matching over an actor's valid messages which means more refactoring but possibly also means in the case of adopting tokio based actors we can have more transparent and easier to follow code.
I believe this should occur after we have a working prototype connected to the evm
The text was updated successfully, but these errors were encountered:
Had some progress on prototyping this have managed to merge Actix API with tokio actors. I just want to see if it is possible to implement async handlers and we may avoid refactoring to a more complex system.
Unfortunately I discovered on their discord last night that Actix is going to be deprecated in a few months. The recommendation the Actix team have been suggesting is to follow the patterns within this excellent post on how to use tokio to create actors another possibility would be to use ractor I think there are tradeoffs for both approaches.
Actix itself was written before async or tokio was a thing in Rust and it has been playing catch up despite being eventually built with it. Since then Tokio actually provides some good async channel primitives we can use which Actix defined itself.
This opens up opportunities to fix some of the annoying things about Actix:
We would want to attempt to avoid using too much boilerplate in our adoption of the Actor model although it requires a fair amount of generic gymnastics to avoid matching over an actor's valid messages which means more refactoring but possibly also means in the case of adopting tokio based actors we can have more transparent and easier to follow code.
I believe this should occur after we have a working prototype connected to the evm
The text was updated successfully, but these errors were encountered: