Cap'n Web: a new RPC system for browsers and web servers • Hacker News Board

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

#301

Post by indolering » Fri, Sep 26, 2025, 11:06 AM UTC

kentonv wrote: post #194

indolering wrote: post #189

Earlier quoted context omitted.

You can generate TypeScript schema for Haxe JS output. I'm honestly a bit surprised that TS isn't a supported target! That could change with some investments. Haxe is a great toolkit to develop libraries in because it reduces the overhead for each implementation. It would be nice to see some commercial entity invest in Haxe or Dafny (which can also enable verification of the reference implementation). > The moment th…

> So this just won't be used outside of Node servers then? Well... I imagine / hope it will be used a lot on Cloudflare Workers, which is not Node-based, it has its own custom runtime. (I'm the author of Cap'n Web and also the lead developer for Cloudflare Workers.)

We've actually chatted before . I was also asking dumb questions that you were polite enough to suffer through .

I really do wish Haxe would get the attention of library developers like yourself. It's more like a framework for polyglot development. It can auto generate non-ergonomic libraries that feel like FFS automatically but you can also gradually fine tune it to match the target language over time. It really helps to centralize development effort and share burden.

So sure, maybe not Rust. But Haxe's distributable size would be comparable.

Maybe I'll try a Dafny implementation to see how that project is coming along!

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

#302

Post by mpweiher » Fri, Sep 26, 2025, 8:22 PM UTC

kentonv wrote: post #292

mpweiher wrote: post #284

Earlier quoted context omitted.

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" becaus…

Hi Kenton,

Thanks for that reply, I’ve never seen my thesis from Can programmers escape the gentle tyranny of call/return[1] expressed so perfectly.

Let me explain: First, I think we are in violent agreement that there is a mismatch between, for example, the REST architectural style of the WWW and the call/return architectural style that we have in most programs. An architectural mismatch that needs to be bridged with great effort. Second, we can probably also agree that the call/return architectural style is hard-coded into pretty much all of our so-called “general purpose” programming languages (C, C#, C++, Java, Rust, Swift, …). I call this architectural/linguistic mismatch.

And third, we as software developers are so used to this state of affairs, the we pretty much perceive “programming” to simply be “writing procedures/functions/methods”. Mary Shaw writes pretty much the same in Myths and mythconceptions: what does it mean to be a programming language, anyhow?[2]

So REST is not “wrong”, it is different from what we are used to. And it is also not “weird”, that is, again, a function of what we are used to.

And REST is clearly not “wrong” because somehow call/return is successful. The world’s largest software system, the WWW is built on REST. (And no, REST was not invented afterward to shoehorn something into something, REST is the architectural style of the WWW[3]).

When I saw teams writing ungodly amounts of code to wrap REST APIs in “nice” procedural APIs”, again and again, the waste also struck me. However, I took the opposite route: In-Process REST[4] uses REST to structure programs internally. The results were amazing whenever I applied it, partly because REST is much, much more composable than procedure calls. And that was in languages that did not support REST natively.

I then created a language that does support REST natively[4] and you get a nice concept of a Storage Combinator out of it[5].

[1] https://dl.acm.org/doi/10.1145/3397537.3397546

[2] https://dl.acm.org/doi/10.1145/3480947

[3] https://ics.uci.edu/~fielding/pubs/dissertation/abstract.htm

[4] https://objective.st

[5] https://2019.splashcon.org/details/splash-2019-Onward-papers...

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

#303

Post by kentonv » Fri, Sep 26, 2025, 8:37 PM UTC

kiitos wrote: post #300

kentonv wrote: post #294

Earlier quoted context omitted.

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

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.

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

#304

Post by kiitos » Fri, Sep 26, 2025, 9:14 PM UTC

kentonv wrote: post #303

kiitos wrote: post #300

Earlier quoted context omitted.

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

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

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

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

#305

Post by kentonv » Fri, Sep 26, 2025, 9:42 PM UTC

kiitos wrote: post #304

kentonv wrote: post #303

Earlier quoted context omitted.

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

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

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.