> Why don't we criticize the author for his lack of Petri nets, or his glaring omission of a denotational semantics in the appendix to his article?
Oh, was I asleep when Petri nets and denotational semantics are now used by millions of programmers around the world?
> Those futures/promises in every web browser in the world are a purely local asynchronous programming idiom, or what I like to think of as CPS unconversion. I didn't suggest that browser programming is a niche concept, but it also has nothing to do with organizing idempotent remote state changes over a lossy message channel.
Of course it does, and I already made this point so I don't know why you're ignoring it. Add durability to browser promises, and there you go. The durability is irrelevant to the semantics.
> Do you run around the IETF and W3C telling them to stop saying "Message-ID" when they really mean futures/promises? Or security researchers with their nonces?
Nonces and Message-IDs have different semantics than promises. It's like you're not even listening.
Idempotency keys have the same semantics as promises. Ergo, they are promises. Promises are idempotent, but not every idempotent abstraction is a promise. It's simple, I'm not sure where the confusion lies.
You seemed fixated on establishing the primacy of the E programming language as the inventor or rightful heir to the use of keys to correlate messages and establish idempotent operations. So, I casually mentioned "prior art" of keys used to manage message retry, deduplication, and replay avoidance.
For more complete examples, consider SMTP, NNTP, and their UUCP predecessors which provided idempotent message transfer and eventually-consistent replication using client-generated, globally distinct IDs. I absolutely fail to see how these are different than a tweet ID or any similar solution for the web. It is such standard practice, we take it for granted like the use of 2's complement arithmetic.
The concept's reappearance in Twitter, Instagram, countless bespoke CRUD applications, or the PostgreSQL example in this article are not "actually promises" just because they're on the web. They are just the umpteenth instance of source-labeled resources being tracked in a distributed system. That is the web abstraction: a resource is created and we do not care whether it is an event, object, message, computational job, bank transaction, or packet of curry being delivered to my doorstep next Tuesday.
A Javascript promise is a local transform for asynchronous control flow. It has zero intrinsic connection to any IO performed in that flow, nor in the remote computation or storage that might occur. The programming language stops where the message leaves the language's runtime and enters the real world of distributed systems. It is not the control flow syntax which makes my communication idempotent, it is me and the recipient agreeing to overlay idempotence semantics on some data we agree to encode into our messages.
Message formats have nothing to do with programming languages. This is how we understand Internet architecture. The local programming language and programming paradigm of each node in the distributed system is immaterial to the messaging semantics and interop standards and their concepts.
Oh, was I asleep when Petri nets and denotational semantics are now used by millions of programmers around the world?
> Those futures/promises in every web browser in the world are a purely local asynchronous programming idiom, or what I like to think of as CPS unconversion. I didn't suggest that browser programming is a niche concept, but it also has nothing to do with organizing idempotent remote state changes over a lossy message channel.
Of course it does, and I already made this point so I don't know why you're ignoring it. Add durability to browser promises, and there you go. The durability is irrelevant to the semantics.
> Do you run around the IETF and W3C telling them to stop saying "Message-ID" when they really mean futures/promises? Or security researchers with their nonces?
Nonces and Message-IDs have different semantics than promises. It's like you're not even listening.
Idempotency keys have the same semantics as promises. Ergo, they are promises. Promises are idempotent, but not every idempotent abstraction is a promise. It's simple, I'm not sure where the confusion lies.