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.