Very glad to see this emerge, we have been using actix in production for a year now and it's a bit annoying the state of it. The dominant sentiment in the Rust community right now seems to be to build your own framework, but I really don't agree with this sentiment.
Regarding the implementation, I would have preferred to have different handler implementations for the various message types instead of a big enum. It's not rare to have 4-5 messages for a single actor and the current approach will make it messy very fast.
One big thing of actix is the ability to control the concurrency of message processing in the async case (sequential or parallel). How does Ractor does it?
1. If you would want independent message handlers, normally we'd just add functions off the state which would be called strait from the message handler's match statement. I.e. something like self.handle_msg_1(message, state, ...). We looked at having multiple handlers but you kind of either get into generic's hell or having to do some kind of ugly proc macro. We figured this left it up to the implementor on how you want to handle it
2. Sequential processing would really be a factory. That would do parallel work of jobs using a basic actor implementation while handling concurrent work limits, job routing, etc. Otherwise you could always spawn inside your actor and like a wait on multiple handles if you wanted, but that gets messy and kind of diverges from the true intent. There is a factory implementation in the base ractor lib, feel free to take a look!
Regarding the implementation, I would have preferred to have different handler implementations for the various message types instead of a big enum. It's not rare to have 4-5 messages for a single actor and the current approach will make it messy very fast.
One big thing of actix is the ability to control the concurrency of message processing in the async case (sequential or parallel). How does Ractor does it?