Some frameworks make a network call look exactly like an ordinary method call on a local object. Explain what that abstraction cannot hide, and contrast it with languages and runtimes that keep remoteness visible in the syntax or the type.

## The promise and the four things it cannot keep Distributed-object systems — CORBA, DCOM, Java RMI, and every "just call the service like a bean" framework since — sell one idea: the caller writes `store.get(key)` and does not care whether the object is in this process. Waldo, Wyant, Wollrath and Kendall's 1994 note "A Note on Distributed Computing" enumerated the four differences that survive any such layer. **Latency** changes by four to six orders of magnitude. Code shaped for cheap calls — a loop of accessors, a chatty interface — becomes unshippable, and the fix (batching, coarse-grained calls) is an interface redesign, not a configuration change. **Memory access** is not shared. Local calls pass references and mutate in place; remote calls copy. Aliasing, identity and mutation-visible-to-both stop working, which is why every RPC system grows a serialization model and every serialization model grows an argument about cycles and identity. **Partial failure** has no local analogue. A local call either returns or throws, and the callee's state and the caller's state agree. A remote call can succeed at the callee and be lost on the way back, so a retry is a second execution. Idempotency keys and at-least-once semantics exist because of this one difference; a transparent call site has nowhere to express them. **Concurrency** arrives uninvited: remote objects serve many callers, so invariants that held under single-threaded local use no longer hold. ## Designs that keep remoteness visible **Erlang and Elixir** never offered the illusion. Sending is an operator, `Pid ! Message`, not a call; a reply is an explicit `receive` with an `after Timeout` clause; there is no shared memory to lose because processes never shared any; and partial failure is modelled directly with `link`/`monitor` plus supervisors that decide restart policy at the level that can. Locality is one axis: the same send works to a process on another node. What you give up is convenience — request/response correlation, timeouts and retries are your code, or a library like GenServer's `call`, which reintroduces a blocking wrapper *with an explicit timeout argument*. **Go** keeps the call shape but forces the differences into the signature: `ctx context.Context` carries deadline and cancellation, and `(T, error)` makes failure a value you must handle. The discipline is conventional rather than enforced — `_ = err` compiles — but the reader sees a network boundary in the parameter list. **Cap'n Proto and its ancestor, the E language**, change the calling *semantics*: a remote invocation is an eventual send that returns a promise immediately, and you may invoke methods on that promise before it resolves. The server-side pipeline runs dependent calls in one round trip — `root.getFolder().getFile().read()` costs one network trip, not three. That optimisation is unavailable to any system whose selling point is that a remote call looks like a blocking local one, which is the sharpest argument that transparency is not free convenience but a lost capability. ## Function colour: the same leak inside one process The visibility question recurs without a network. JavaScript, C# and Kotlin mark asynchrony in the signature (`async`, `suspend`), so a leaf function turning remote propagates upward through every caller — the "colour" problem — and blocking on a result can deadlock (classic ASP.NET's captured synchronization context on `.Result`). Go's goroutines and Java's virtual threads deliberately uncolour: blocking is cheap, so ordinary call syntax stays. The tradeoff is exactly the one above — uncoloured code reads uniformly and hides which calls do I/O; coloured code advertises it and forces mechanical churn when a boundary moves. ## What to do as an architect Make the boundary a designed artefact: coarse-grained operations sized for one round trip, explicit deadlines, an explicit failure type, and an idempotency story for retries. Do not let a code generator produce local-looking interfaces and call that an architecture. Where the ecosystem hides remoteness, restore it in the type you expose — return a result type that includes failure, take a deadline parameter — so the caller cannot forget what the network already knows.