Wow. I've read some of Vinoski's columns about this, and they're very good. But the following is absolutely the clearest explanation of why you can't abstract away the network that I've ever seen:
"The fundamental problem is that RPC tries to make a distributed invocation look like a local one. This can't work because the failure modes in distributed systems are quite different from those in local systems, so you find yourself having to introduce more and more infrastructure that tries to hide all the hard details and problems that lurk beneath. [...] But it's all for naught because no amount of infrastructure can ever hide those problems of distribution. Network partitions are real, timeouts are real, remote host and service crashes are real, the need for piecemeal system upgrade and handling version differences between systems is real, etc. The distributed systems programmer must deal with these and other issues because they affect different applications very differently; no amount of hiding or abstraction can make these problems disappear."
This would be more impressive if it wasn't cribbed almost verbatim from a Tanenbaum paper that, judging from the popularity of this thread, nobody seems to have read.
This would be less obnoxious if it actually included a citation instead of merely insinuating, and didn't tacitly insult those who haven't read everything.
The phrase "remote procedure call considered harmful" does not appear on Google. You must be talking about "A Critique of the Remote Procedure Call Paradigm", which I tracked down (http://www.cs.vu.nl/~ast/publications/euteco-1988.pdf) and have now read. It's a good paper, and remarkably early for the insights it contains, six years before the more famous "Note on Distributed Computing". Since most of the work done on RPC was done after this paper, including all the time Vinoski spent on CORBA, I wonder what he'd say about it now (as compared to what he'd have said about it then). I'm glad to have read it and thank you for the reference.
To say that Vinoski's words were "cribbed almost verbatim" from this paper is beyond even gross exaggeration. I think you should be less cavalier about flinging accusatory phrases. The quote obviously isn't original, but it still is absolutely the clearest explanation of the core insight that I've seen. Vinoski sums it up in one marvelous paragraph; that is a very different thing from a 10-page technical article, even if the content were identical, which it isn't.
As for "you really should have read this by now", sure. I really should have read Proust by now too.
You really are taking board comments seriously today. How long did this take you to write? I'm glad you liked the paper I pointed you at. I stand by my assertion, which is that it's puzzling that practitioners are abuzz about Vinoski's post, which reiterates an ancient sentiment about RPC.
You really are taking board comments seriously today.
Ha. That is true. And now you've made me laugh.
Since obviously nobody else is following this, here's a completely frivolous story that just popped into my mind. I was at a software conference and ended up talking to a pretty famous guy. A second (not quite as) famous guy walked by. After he was gone, the first guy told me that two evenings earlier, on the night before the conference, they had bumped into each other in a hotel corridor, and the second guy had said, "Good." - and kept on walking. "What do you mean, good?" the first guy called after him. Second guy's reply: "I'm not the biggest asshole here."
"The fundamental problem is that RPC tries to make a distributed invocation look like a local one. This can't work because the failure modes in distributed systems are quite different from those in local systems, so you find yourself having to introduce more and more infrastructure that tries to hide all the hard details and problems that lurk beneath. [...] But it's all for naught because no amount of infrastructure can ever hide those problems of distribution. Network partitions are real, timeouts are real, remote host and service crashes are real, the need for piecemeal system upgrade and handling version differences between systems is real, etc. The distributed systems programmer must deal with these and other issues because they affect different applications very differently; no amount of hiding or abstraction can make these problems disappear."