Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cap'n Web: a new RPC system for browsers and web servers

blog.cloudflare.com

Post reply on HN
Print view View original

291–300 of 305 posts

Re: Cap'n Web: a new RPC system for browsers and web servers

#291

Post by closeparen »

kiitos wrote: post #286
closeparen wrote: post #182

Earlier quoted context omitted.

CORBA is trippier than that. A client’s request could include elements not normally serializable, like callbacks. A server could provide an object in response to your query and then continue mutating it, with the mutations reflected (effectively) in your address space, without your knowledge or participation.

I am not really sure what you're talking about RPC is "remote procedure call", emphasis on "remote", meaning you always necessarily gonna be serializing/deserializing the information over some kind of wire, between discrete/different nodes, with discrete/distinct address spaces a client request by definition can't include anything that can't be serialized, serialization is the ground truth requirement for any kind of…

Nothing stops me from implementing a Thrift or gRPC handler that uses a field from the request to look up an object in a hashmap and then call one of its methods with data from the request. But a distributed object system will do this implicitly on my behalf, so that the programmer’s perspective is like passing objects (by reference) over the network.

Re: Cap'n Web: a new RPC system for browsers and web servers

#292

Post by kentonv »

mpweiher wrote: post #284
kentonv wrote: post #254

Earlier quoted context omitted.

Eh, I think composed function calls have legitimately won _because_ they compose well and are easy to understand, not just because we haven't tried other things.

1. The WWW would like a quick word with you regarding function calls having won. 2. You are making an invalid assumption, which is that we only get to have one tool in our toolbox, and therefore one tool has to "win". Even if function calls were the best tool, they would still not always be the right one. With the benefit of hindsight, it’s clear that these properties of structured programs, although helpful, do not…

> The WWW would like a quick word with you regarding function calls having won.

Nope, HTTP got it wrong. HTTP was designed to fetch files -- GET and PUT. It's fine at that. REST was invented as a way to shoehorn APIs into the model of HTTP. It's a weird model that's very different from regular programming, and people have a really hard time thinking about it. But some people argued that REST is the "right way" because it fits into this HTTP model that was never designed to support APIs in the first place. And other people said "yeah that makes sense" and went along with it.

Enormous amounts of effort are spent implementing REST APIs that wrap underlying programming language APIs, and then writing client libraries that implement the programming language APIs again on top of REST primitives.

It's all a waste. If the industry had taken a different path and focused on network protocols that model programming language APIs all along, I think we'd be in a much better place. Better late than never, though.

> 3. Procedure calls are not particularly composable > > See CORBA vs. REST.

I never personally used CORBA, but I have a lot of experience building big distributed systems on Cap'n Proto and I've found it far more composable than REST.

Re: Cap'n Web: a new RPC system for browsers and web servers

#293

Post by kentonv »

kiitos wrote: post #288

> 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 forma…

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.

Re: Cap'n Web: a new RPC system for browsers and web servers

#294

Post by kentonv »

kentonv wrote: post #293
kiitos wrote: post #288

> 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 forma…

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…

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.

Re: Cap'n Web: a new RPC system for browsers and web servers

#295

Post by adzm »

javier2 wrote: post #282
adzm wrote: post #116

Earlier quoted context omitted.

The lambda is converted into an Expression, basically a syntax tree, which is then analyzed to see what is accessed.

Ok, so its a step in the compile that rewrites and analyzes it?

It's actually really neat. Normally a lambda would just be a function but if it gets cast to an Expression then you get the AST at runtime. Entity Framework analyzes these at runtime to generate the SQL and logic/mapping etc. You can get the AST at compile time in some situations with a Roslyn plug-in or etc I believe as well.

Re: Cap'n Web: a new RPC system for browsers and web servers

#296

Post by benpacker »

losvedir wrote: post #106

Babe get in here, a new kentonv library just dropped! I'm surprised how little code is actually involved here, just looking at the linked GitHub repo. Is that really all there is to it? In theory, it shouldn't be too hard to port the server side to another language, right? I'm interested in using it in an Elixir server for a JS/TS frontend. For that matter, the language porting seems like a pretty good LLM task. Did…

I think crossing a language barrier here would be hard: you'd need a codegen step to compile the RPC spec to Typescript for the client-side DX and that would need take into account the full range of differences in serializability across the languages.

For cross-language RPC, I think we're still better sticking to a well defined system where the spec is data (OpenAPI, GraphQL, etc.) instead of the spec being code that only one side understands.

Re: Cap'n Web: a new RPC system for browsers and web servers

#298

Post by kentonv »

benpacker wrote: post #297

Does this have support for generators / streams, or any ideas how you'd do it? With LLMs that an increasingly large part of client/server communication.

It does better. It supports callbacks, including callback objects with multiple methods. So to define a stream, you just send the other side an object with a `write()` and an `end()` method. The other side calls `write()` for each chunk of the stream, then eventually calls `end()`. You can also give the stream a `[Symbol.dispose]()` method which will be called when the other side disconnects, so you can detect premature disconnect.

Re: Cap'n Web: a new RPC system for browsers and web servers

#299

Post by kiitos »

kentonv wrote: post #293
kiitos wrote: post #288

> 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 forma…

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…

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

Re: Cap'n Web: a new RPC system for browsers and web servers

#300

Post by kiitos »

kentonv wrote: post #294
kentonv wrote: post #293

Earlier quoted context omitted.

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…

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…

> 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

Post reply on HN