[naasking]

> A remote call fails, the error propagates up the call stack, and someone gets an error message.

Uh-huh, but did the message actually get through? Can they safely just retry? These are very uncommon failure modes on local systems but very common on networked systems. Without a proper stateful abstraction beyond just "procedure call", like a promise, you can't address these failure modes properly.

> In the rare case you need to harden a particular call, you add caching or retries or whatever other logic fits your use case

Which now makes your system nondeterministic like I said.

> Even javascript added await because it's better to pretend that async code looks synchronous

Yes, linear code is easier to read. I don't see what this has to do with anything. The use of promises and await indicates a possibility of failure semantics that would otherwise not be apparent in the program's control-flow.

Yes, you can superficially make this look like synchronous code, but it's not synchronous code.

[lelanthran]

> Uh-huh, but did the message actually get through? Can they safely just retry?

...

> The use of promises and await indicates a possibility of failure semantics that would otherwise not be apparent in the program's control-flow.

They don't, though. They don't indicate if the message got through. They don't indicate if you can safely retry. Their failure mode is exactly as opaque or as transparent as synchronous calls.

The reason for their existence and mandatory use in Javascript is due to a deficiency of the platform (single thread, so all synchronous calls block).

If the platform was better they would never have existed.

[naasking]

> They don't, though. They don't indicate if the message got through. They don't indicate if you can safely retry. Their failure mode is exactly as opaque or as transparent as synchronous calls.

The promise is at the remote end. Promise resolution is idempotent, so retries always resolve to the same value. These are correct promise semantics as pioneered in the E language.

[lelanthran]

> The promise is at the remote end.

What? The promise is local, so what do you mean "the promise is at the remote end?"

> Promise resolution is idempotent,

No. It is only run once (whether resolve or success), that does not mean it's idempotent.

Just like exceptions for synchronous code, or error returns.

[naasking]

Nothing personal, but people not aware of where these concepts came from in distributed computing history is annoying, and I don't like repeating myself:

http://erights.org/elib/distrib/captp/index.html

[lelanthran]

Regardless of where promises come from, the fact is that they are locally resolved, not remotely resolved.

Using promises in JavaScript is a hack around the fact that the platform has some pretty large deficiencies.

[naasking]

> Regardless of where promises come from, the fact is that they are locally resolved, not remotely resolved.

Idempotent operations are implicit promises at the protocol level. We're talking about distributed systems here where abstractions and semantics cross machine boundaries, so your local-only focus is not valid. I suggest reading up on the E language via the link I provided.

> Using promises in JavaScript is a hack around the fact that the platform has some pretty large deficiencies.

A single threaded event loop is not necessarily a deficiency.

[stickfigure]

> you can't address these failure modes properly.

Again, total nonsense. There's nothing special about a promise. Whatever logic you can build on promises is easier to build synchronously. Everything that applies to building distributed systems applies whether you use rpc stubs or promises. Promises are just noisier and harder to reason about.

[naasking]

Maybe we're speaking past each other. Idempotent operations are implicit promises. Network partitions require idempotency at some level to ensure robustness. That means any robust distributed protocol requires promises at the core protocol level.

Trying to hide the promises behind a synchronous client interface is unnecessarily constraining and inefficient, like requiring large stack contexts that can't be restarted or persisted, and so can't be simply resumed after partitions.