3 ms·
> 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
by naasking 3y ago
> 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 3y ago> 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 3y agoNothing 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 http://erights.org/elib/distrib/captp/index.html
- lelanthran 3y agoRegardless 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 3y ago> 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.