Tom Van Cutsem at
Wed Nov 7 08:57:54 PST 2012

2012/11/7 Kevin Smith <khs4473 at>

> In other words, futures provide synchronisation, while promises
>> provide resolution.
> This is exactly the API that Q (and it's derivatives) use, although the
> nomenclature is different.  In Q, the "future" is called a promise, and the
> "promise" is what you get from calling defer():
>     let { resolve, reject, promise } = Q.defer();
> I think the nomenclature you've provided is superior.

While we're talking nomenclature: the terms "promise" and "future" also
appear, with roughly the semantics described by Andreas in Scala's API [1]
and Clojure's API [2] (both very recent APIs). I know MarkM dislikes the
use of these terms to distinguish synchronization from resolution, as he
has long been using those same terms to distinguish traditional "futures",
which provide a .get() method blocking the calling thread and returning the
future's value when ready (as in e.g. Java), from "promises", which only
provide a non-blocking "when" or "then" method requiring a callback, never
blocking the event loop thread (as in all the Javascript promise APIs).

To my mind, the term "future" is still very closely tied to blocking
synchronization. YMMV.

There's a helpful Wikipedia article that compares and contrasts some uses
of the terms [3].


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

More information about the es-discuss mailing list