> Why RPC? (And what is RPC anyway?)

RPC is an ambiguous and abstract umbrella-term for any request-response communication between two nodes that don't share the same memory space, usually over a network connection, and always via serialized bytes.

> Without RPC, you might communicate using a protocol like HTTP.

HTTP is probably the most common protocol for implementing RPC, indeed

> With HTTP, though, you must format and parse your communications as an HTTP request and response, perhaps designed in REST style.

yep! HTTP/REST is one good option, among many, for doing RPC communications

> RPC systems try to make communications look like a regular function call instead, as if you were calling a library rather than a remote service. The RPC system provides a "stub" object on the client side which stands in for the real server-side object.

Er, no, if you introduce the concept of "objects" you're now talking about something quite different than RPC, more akin to CORBA, which we well know now is not sound...

> When a method is called on the stub, the RPC system figures out how to serialize and transmit the parameters to the server, invoke the method on the server, and then transmit the return value back.

I mean, sure, but this is just normal serialization protocol stuff, right?

> The merits of RPC have been subject to a great deal of debate. RPC is often accused of committing many of the fallacies of distributed computing. But this reputation is outdated. When RPC was first invented some 40 years ago, async programming barely existed. We did not have Promises, much less async and await. Early RPC was synchronous: calls would block the calling thread waiting for a reply. At best, latency made the program slow. At worst, network failures would hang or crash the program. No wonder it was deemed "broken". Things are different today. We have Promise and async and await, and we can throw exceptions on network failures. We even understand how RPCs can be pipelined so that a chain of calls takes only one network round trip. Many large distributed systems you likely use every day are built on RPC. It works.

What a confusion of terms and concepts! Promises and async/await are language-level concepts, completely orthogonal to "RPC" which is a transport/wire-level concept -- what is happening here!! :o

> The fact is, RPC fits the programming model we're used to. Every programmer is trained to think in terms of APIs composed of function calls, not in terms of byte stream protocols nor even REST. Using RPC frees you from the need to constantly translate between mental models, allowing you to move faster.

i do not think RPC means what this author thinks that it means

▲

kentonv 2 days ago | parent [-]

You're simultaneously being pedantic and at the same time anti-pedantic here.

Sure, you can kinda-sorta argue that HTTP is an RPC protocol, insofar as it is request/response oriented, and so is RPC. But obviously I was describing RPC systems that model programming language APIs more closely than HTTP does.

Yes, technically the P in RPC stands for "procedure", and procedural programming vs. object-oriented programming are different things. If you're really calling methods on objects then "procedure" is a misnomer. Maybe you could call it RMI (remote method invocation), except that that's a Java-specific term. Another term you could use -- and which, obviously, I did use, repeatedly -- is "object-capability model", but that is actually a bit more specific than just being object-oriented. There's no well-known term for "RPC except objects". Well, actually there is: it's just "RPC". People have been calling this "RPC" for decades, even though it's "technically wrong".

> more akin to CORBA, which we well know now is not sound...

The point of this text was to contest this notion, but here you haven't really made a counter-argument, you've just asserted that we "know" it is "not sound".

> Promises and async/await are language-level concepts, completely orthogonal to "RPC" which is a transport/wire-level concept

The argument here is that the reason CORBA failed is because it lacked the language-level concepts to make it work well, in particular strong asynchronous programming primitives and promise pipelining.

> i do not think RPC means what this author thinks that it means

lol yeah what do I know about RPC.

▲

kiitos a day ago | parent | next [-]

> The argument here is that the reason CORBA failed is because it lacked the language-level concepts to make it work well, in particular strong asynchronous programming primitives and promise pipelining.

i'm honestly not sure how to respond to this

CORBA failed because it didn't understand or accommodate the fundamental constraints of distributed computation. specifically the idea that you could define a useful abstraction of an object that worked the same way whether the implementation was local or remote. this is a protocol/design level error, nothing to do with any language-level concept, like async primitives or promise pipelining or whatever. i'm not sure how those things even entered the discussion? and i'm not trying to be glib, i'm really just re-iterating basic "lessons from CORBA 101" type stuff, which I've understood as common knowledge since the mid 90's...

▲

kentonv 2 days ago | parent | prev [-]

I should clarify, lack of proper language-level support for async programming wasn't the only problem CORBA had. Its main problem was that it was just massively overcomplicated and tried to do way too much. It went way beyond just being a protocol, it specified "object resource brokers" and such.

But it did also make the mistake of being designed around synchronous calls, only adding an async mode later on, and when it did add async, it was excessively complex to use, due in part to the missing language features.

I'm not sure what you mean when you say it was "unsound". Excessive complexity isn't really a matter of soundness. So I assumed you were referring to the more general criticism that has historically been raised against RPC, which is that trying to make network calls look like local calls hides important details which distributed applications must handle, like latency and network instability. My argument is that asynchronous programming, promise pipelining, and exceptions largely solve these issues just fine, and practical experience backs this up.

▲

kiitos a day ago | parent [-]

> trying to make network calls look like local calls hides important details which distributed applications must handle, like latency and network instability.

among many other concerns, yes

https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

> My argument is that asynchronous programming, promise pipelining, and exceptions largely solve these issues just fine, and practical experience backs this up.

you can't solve fundamental distsys problems at the language level (lasp &c. notwithstanding)

hopefully not controversial

▲

kentonv 2 hours ago | parent [-]

Yes, I'm aware of the fallacies of distributed computing. I literally linked to it in my post. You quoted the place where I linked it in your original comment above.

> you can't solve fundamental distsys problems at the language level (lasp &c. notwithstanding)

The "fundamental distsys problem" here originates in the language level: the problem is the attempt to hide the existence of a network protocol from the application code. The network protocol itself isn't at fault for this; the client library is.

So yes, of course it can be solved at the language level.

▲

kiitos an hour ago | parent [-]

> The "fundamental distsys problem" here originates in the language level: the problem is the attempt to hide the existence of a network protocol from the application code.

so the problem isn't about whether or not the application knows a network protocol is involved. it's that state has fundamentally different semantics when any network protocol gets involved.

languages, SDKs, etc. all exist "on top" of networks in the abstraction sense, once you start sending bytes between nodes over unreliable links then that stuff dictates the rules that you gotta abide by, you know?

	▲	kentonv an hour ago \| parent [-]
		Sure. And Cap'n Proto/Web provides tools for handling that. And they work, as evidenced by one of the largest and highest-traffic distributed systems in the world (Cloudflare Workers / Durable Objects) being built on Cap'n Proto.