I assume that the author is indeed referring to the fact that all APIs are about simple, marshallable values. You can't pass references to a remote server, and

I assume that the author is indeed referring to the fact that all APIs are about simple, marshallable values. You can't pass references to a remote server, and the remote server can't return a reference to a remove object. I don't know Cap'n'Proto's RPC at all (I looked at it briefly for some projects, but rejected it since we needed Ruby support), but I've worked with CORBA, Microsoft's COM (specifically, DCOM) and Java's RMI. These all let you pass around references to remote objects. The danger in these systems is that that every API is locality-transparent, you don't know if any given call will be to remote object or a local object. You can be super careful about what you pass around, and still end up doing remote calls by accident. It also leads to "normalized" API designs that too easily incur 1+N roundtrips even for basic information retrieval; for example, an endpoint that returns Book[], where each book has an Author, accessing book.author ends up with a network roundtrip to get the author. I very much prefer the dumb-but-explicit approach where APIs only exchange data, and you only exchange data. Another big challenge that DCOM struggled (and, I think, CORBA and RMI) with was object releasing. DCOM, for example, had explicit reference counting. This meant that a client could hold onto an instance for a long time, and that while doing so the server also had to keep the instance around. If a client died, keepalive logic in the DCOM framework would eventually release the object. Perhaps the biggest challenge in any DCOM server was thread safety. Since any client could come in on a separate thread, your entire API model had to be thread-safe, or rely on thread-safe wrappers that acted as proxies for your real internal data objects. I should say that locality transparency is very nice to work with — until you start having issues.