Essentially it all boils down to theory vs practice, where the beautiful theoretical concepts fell prey to the various fallacies of distributed computing:
Imo only Erlang really gets this right, and QnX did a halfway decent job of it at the 'OS on bare metal' level. Everything else is just endless duct tape and baling wire.
Erlang is so far the only environment I know that took the plunge of expanding the domain of "RPC call" into things that are, technically, local. Thus harmonizing local and remote calls to a much greater degree. Although it's still hard to hide the potential latency differences no matter what you do.
This is one of the reasons that even though I'm kinda down on actually using Erlang for a real system, I really recommend any aspiring language designer spend some time with it. Like Haskell, many languages have copied some of its surface aspects, but few languages are capturing its unique deep value proposition. I live without it because on the balance I prefer other things, but what would be even better is having both my later conveniences and capabilities and Erlang's wisdom.
I've noodled around with trying to construct a language where the lower guarantees of an RPC call are the default, and you have to "declare" that you want to "cast" an RPC-like API into a static local API, which is then compiler-time checked for being valid to do that with. I haven't got very far beyond the "drool on a napkin" phase for it though.
Indeed, and it is why I think the Erlang solution is the way to go: you can't get there by expanding the concept of 'local' to the special case of 'remote', but you can take the 'general case of remote' and then take some shortcuts to give you a speed advantage if the call turns out to be local. That saves you having to keep two ways of doing things in your head and makes sure you get it right every time instead of just the times that you were thinking about it hard beforehand. As for latency: yes, you can't fake that, but interestingly, if you pick the boundaries of your services carefully then you can go a surprisingly long way before that becomes a problem.
The concept you are describing sounds interesting, it would be a nice middle ground. QnX has some of this in their send/receive/reply combo, there the default destination host is the localhost, and because that is abstracted away you will always specify the counterparty so your code will already be network aware. QnX admins are what we'd call services and they can be as simple or as complex as you want, including a whole new cluster behind a simple endpoint. I've built some pretty complex installations with that (100's of servers, 1000's of processes) well before 'infrastructure as code' was a thing and the reliability and response you'd get from that was unlike anything that is on the market today.
But Erlang, assuming your problem doesn't require a lot of computation (which very unelegantly escapes to C) and fits nicely in with the OTP concept (which is almost all code that is communications and CRUD like constructs) it is as slick as it gets all the way to having the supervision, monitoring and start-up seamlessly built into the environment.
I wished I had a good excuse to build something for real with it.
https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...
Imo only Erlang really gets this right, and QnX did a halfway decent job of it at the 'OS on bare metal' level. Everything else is just endless duct tape and baling wire.