In particular, if the "network" is something local to one machine, pcie or some cross-chip fabric thing, where the failure modes of the "network" are the box falls over, then RPC works as one might hope. You don't have to mangle functions to take account of extra network errors because there are none.
The specific use case I'm interested in is heterogenous compute on shared memory machines. Code running on a GPU can call `int rc = fprintf(stderr, "oh dear");` and have no idea whether that runs code on a CPU or not. Code running on a CPU can call some linear algebra function and either run it locally or on a GPU, unobservable to the caller.
That is a good trick. It does make for an interesting debugging experience where you lose track of where code is executing.
----
There's a less esoteric application in the area of the OP for pure functions where you don't need the result immediately. That goes something like:
1. Call the function and get back a promise or similar. All runs locally, no failures
2. Something in the background maybe does the work for you
3. Ask for the result. If it's not available yet, do the work locally
That has the same zero failure modes property because it'll ultimately run all the work locally if the network offloading never works out. It only really makes sense if the functions can be called multiple times (e.g. locally and remote at the same time) without doing harm, i.e. pure functions. It costs latency and gains throughput. For some batch computation work that is great.