Hi mate,

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!

This sort of reminds me of an old agent based Java middleware called Voyager I've encountered sometime in the 90s. The rough idea of this middleware was that you could write Java class derived from a special prototype and the instance of said class can travel around various Voyager servers all over the world to perform tasks on local context and then come back with the answer. Could be used for the whole bunch of scenarios from map reduce to accessing some content that only available at particular place and not accessible by public API. It was neat. Not sure what did happen to this middleware later on.

Hiding the network layer is often problematic.

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.

Have you heard of Citybound? The author has implemented something similar for the simulation of the units in a multiplayer scenario. Cars/houses/people are all actors and can be simulated on any computer in the game and it all just magically works.

They have a talk somewhere where they explain it and do a live demo, pretty neat stuff :)

https://aeplay.org/citybound

Ah. Cool. What are your plans around data serialization and compatibility of different nodes during version upgrade?

And thanks for the answer!

Regarding data serialization, I'm currently using serde_json, however that's just because it's easy to work with for development/testing purposes though I do love the idea of using protobufs!

Node compatibility and I guess distribution overall are problems I'm extremely looking forward to tackling! :)

> though I do love the idea of using protobufs!

or FlatBuffers!

Not sure on rust compatibility, but have you considered Cap’n Proto? https://capnproto.org/

Cap'n Proto has good a good Rust library, but it's overall language support versus alternative formats is somewhat lacking, unfortunately.

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.

Are you familiar with CORBA?