I think the term for this is "location transparency" and it tends not to work well in practice. A local function call and a RPC call over a network have very different performance characteristics and failure modes; trying to abstract away the differences can be a bad scene.
I was aware of CORBA, but have never worked with it. I should have added a link out to it, I might do that.
I think most ideas do have necessary conditions to succeed, and perhaps network latency (especially in single VPC) has improved a lot since those days.
The original motivations weren't just network based. The scenario where I wanted to use CAP_LINUX_IMMUTABLE to create append-only log files via EXT4 attr was a good example of where being able to decorate a function to say that it runs in a separate container potentially seemed like a reusable concept.
> trying to abstract away the differences can be a bad scene
Agree, generally I'm against "magic" behavior in code. That's why I quite like the protobuf philosophy of being able to see the generated code at compile time, as opposed to some runtime magic.
What I'm suggesting is just to abstract some of that boilerplate code, but it could still go badly if used without consideration.
The Erlang VM lets you move actors from your local computer to a different cluster transparently for the caller.
The author seems to be thinking it can be transparent at the method call site, but it’s not really the case: when executed locally, pure functions are guaranteed to return (unless hardware limitations), while remote execution necessarily brings the network issues with it; pure functions could now fail for network reasons, but only when running elsewhere.
Erlang works around this by forcing you to think of calls to actors as messages and to deal with all the network issues that come with it: works both locally and non locally.
A previous journey down this road: https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...