Comment by kentonv | Hacker News Reader

Comment by kentonv | Hacker News Reader

Parent Full thread

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.

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.

> 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

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.

> 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?

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.

> 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...

Reply on news.ycombinator.com