Tom Van Cutsem
tomvc.be at gmail.com
Wed Nov 14 11:37:33 PST 2012
2012/11/14 Andreas Rossberg <rossberg at google.com>
> On 14 November 2012 18:41, Mark S. Miller <erights at google.com> wrote:
> > Either way, Scala's
> > unfortunate choice clearly violates this history in a confusing manner,
> > 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
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! :-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss