Mark S. Miller erights at
Wed Nov 14 12:11:00 PST 2012

On Wed, Nov 14, 2012 at 11:37 AM, Tom Van Cutsem < at> wrote:

> 2012/11/14 Andreas Rossberg <rossberg at>
>> On 14 November 2012 18:41, Mark S. Miller <erights at> wrote:
>> > Either way, Scala's
>> > unfortunate choice clearly violates this history in a confusing manner,
>> so
>> > I'd classify it as #4. Let's not repeat Scala's mistake.
>> Just to reiterate, it's not just Scala, but more importantly also C++,
>> Java (to some extent), and several less mainstream languages. That is,
>> this use of terminology has quite a bit of history of its own, dating
>> back almost as far as E (and having developed more or less
>> independently).
> I still think futures connote strongly with blocking synchronization. If
> we'd add a concept named "future" to JS on the grounds that the same
> concept exists in Java and C++, developers will reasonably expect a
> blocking future.get() method.
> In my experience, the term "promise" is much more associated with
> non-blocking synchronization through .then or .when callback chaining
> (although ironically the name derives from Argus, which featured blocking
> promises. Argh! :-)

OTOH, the Argus promises were where promise pipelining <> was
invented, and this is a key feature of our distributed promises via
.send/.post. In this way, the Argus promises are the closest to ours.

> Cheers,
> Tom

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list