rossberg at google.com
Thu Nov 15 02:44:51 PST 2012
On 14 November 2012 20:37, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> 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.
I'd say that different notions of "concurrency" in respective
languages naturally affect the details of the future _interface_, but
I don't see this as a fundamental difference in the concept _as such_.
Somewhat like weak maps not having iteration, but still being maps.
The future interface in languages with threads is a superset of what
we can provide for JS. In those languages, you (can) have 'then' and
'wait'. Obviously, in a language without threads and only asynchronous
"concurrency", the latter operation is not available.
More information about the es-discuss