Thanks for thinking about distributed actors here, Chris!
As Kavon outlined (thanks! Sorry, I was having such a slow Monday...) we really do not need (or want) "remote initializers" but the systems are built around the concept of resolving remotes. An initializer is always local; this is important and powerful because it allows us to have such actor contain things which only could exist locally -- you can ask a remote "Boss" to get you a "Worker", and the boss can pass non-serializable values to the from itself to the worker, and return to you a reference to that worker etc.
This is also what enables advanced "virtual" actor patterns (popularized by orleans), where you don't ever really know if the remote actor is alive or not at the moment of resolve, but the implementations either give you back the existing one, or could even create a "fresh" one for it -- this relates to the passivation patterns Kavon mentions
Summing up: distributed actor inits are indeed tricky, but because of the injection of the
transport.actorReady(self) call, not because any remoteness of them.
I'd love to catch up in detail by the way, hope to set up something soon
I need to write up a review here about the proposed semantics and the calls we need to inject in these inits, but I worked with Kavon and we're confident the two mesh well together. We didn't want to muddy this proposal with a lot of details about distributed init "actor ready" call injection though -- it'll fit the rules though, so we're fine