domenic at domenicdenicola.com (2013-11-17T18:00:54.485Z)
In summarizing the history, I held back from mentioning names because it is a long history and many people deserve thanks. Nevertheless, a few names stand out so much I can't talk about the history without thanking them: - E. Dean Tribble - Domenic Denicola - Kris Kowal - Tyler Close Without them, E-like promises would never have made it into JS, and if they had they would have been far worse.
In summarizing the history, I held back from mentioning names because it is a long history and many people deserve thanks. Nevertheless, a few names stand out so much I can't talk about the history without thanking them: E. Dean Tribble Domenic Denicola Kris Kowal Tyler Close Without them, E-like promises would never have made it into JS, and if they had they would have been far worse. Thanks! On Tue, Nov 12, 2013 at 4:22 PM, Mark S. Miller <erights at google.com> wrote: > I mean the promises-unwrapping proposal that has now been accepted into > ES6 and the DOM, and IIUC is being implemented by several browser makers. > Let's call these JS Promises. These descend from Promises/A+ which have a > long and complicated history, but the major branches of that history all to > back to E. Approximately: > > JS Promises from Promises/A+ from merge(Promises/A, Q) > Promises/A from Dojo Deferred from MochiKit Deferred from Twisted > Python Deferred from E Promises. > Q from Promises/C from Waterken Q from E Promises > > My point is that the differences between hard references and JS Promises > are exactly the non-transparencies needed to address your non-Stonebreaker > bullets: > > * One cannot ignore network latency and partitioning. > > Latency: > JS Promises are asynchronous and were carefully designed to not preclude > future promise pipelining. Q makes use of this pipelining. > > Partition: > JS Promises have a terminal "rejected" state indicating that they will > never designate any object. This descends directly from the E "broken" > state, where it was was also used to make network partition apparent in a > fail-stop manner. Q makes use of this. > > * Sync RPC is the wrong model (it already yielded to async calls, > futures/promises, and the like). > > Exactly! > > * Weak consistency (I know, people hear "CAP" and give up too much) won, > which surprised some. > > Because Promises are asynchronous, even locally, the state of the world > when a promise-based request is made differs from the one in which the > request is received. Since partition induces rejection of all promises > across that partition, connection recovery takes distinct paths through the > code where one copes, in an application dependent manner, with having been > out of communication. > > Further support for weak consistency should come at a higher level, e.g., > via the Unum model < > https://www.cypherpunks.to/erights/talks/uni-tea/uni-tea.ppt>. Promises > are a good substrate on which to build Una. > > > > > On Tue, Nov 12, 2013 at 3:57 PM, Brendan Eich <brendan at mozilla.com> wrote: > >> Mark S. Miller wrote: >> >>> Link please for the Stonebreaker point? >>> >> >> Sorry, having a hard time finding it now. It was about the longer history >> since SQL was pioneered; also about NoSQL. >> >> >> On your other bullets, you're preaching to the choir. These are exactly >>> the considerations that led to the E promise design, now adopted by JS. >>> >>> http://www.erights.org/elib/concurrency/semi-transparent.html >>> >>> Where it says "<-", substitute "!". >>> >>> In addition, promise pipelining gives us a huge win over network latency >>> beyond the points made on that page. >>> >> >> Fair point. >> >> >> Now that we've adopted such promises, we've paid the anti-transparency >>> costs of good distributed objects. This was quite intentional. Now that >>> we've paid the costs, we may as well collect the benefits. >>> >> >> I think your use of "we" and past tense here are not shared as widely as >> you'd like. Anything deployed on the public web yet? >> >> /be >> > > > > -- > Cheers, > --MarkM > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131112/8441db85/attachment.html>