I wonder if the author could comment on how the goals of this project might differ from those of Actix?
Many people are still new to async/await; did you consider add a runtime/executor in your readme example? I didn’t see the creation of a Runtime to drive the futures, that might be a nice thing to show.
The goal is to eventually have actors spread across multiple servers with automatic load balancing etc. I'm currently working on remote actors, with the goal for the API to be exactly the same whether you're talking to a local actor or a remote actor - it shouldn't matter to the user!
The runtime is just Tokio's runtime, actors are just tasks awaiting on messages (and handling them) from their Receiver!
Cheers!
And thanks for the answer!
Node compatibility and I guess distribution overall are problems I'm extremely looking forward to tackling! :)
or FlatBuffers!
That said, Cap'n Proto has a substantially better design (both in theory and implementation) than any of the alternatives IMO, so it's worth using anyway if your language supports it well. And especially so if you're using it "internally", so other language clients aren't as big of a deal.
They have a talk somewhere where they explain it and do a live demo, pretty neat stuff :)
Networks are much less reliable or predictable than a PCI or SATA bus. You have to honesty handle timeouts, unavailability, retries at the very least.
Hiding this from the user is usually a bad idea. An intelligent handling layer does help, but it cannot e.g. entirely mask unavailability.
So the common interface would have to be the handling-it-all interface, likely as a number if separate traits.