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