Alternative to Promise

[Tab Atkins Jr.]

On Wed, Sep 30, 2015 at 5:18 PM, 韩冬 <handong05 at meituan.com> wrote:
> Yes, i understand it’s too late to revise Promise design, my random thought are:
>
> 1. Why we put Promise into language?

Because it exposes useful functionality.  I recommend reading some of
the Promise explainers that exist for lots of examples.

> Promise are complex state machine, there can be so many variations, each implementation have different performance characteristic, which one should be built into language?

There's only one variation that's standard, and every browser is or
will soon be implementing that one.

The "state machine" isn't complex.  "unresolved" goes to either
"resolved to another promise", "fulfilled", or "rejected".  "resolved
to another promise" eventually turns into "fulfilled" or "rejected".
Or, of course, hangs, which "unresolved" can also do.

> 2. Why we don’t look for continuation based implementation at the first place?

Continuations are a different concept, and don't address what we were
trying to solve when adopting promises.

> Lisp, haskell or even some transpiled to js language like elm use continuation solve callbacks already, why didn’t port them?
> Now we invent a complex state machine based solution, a lot of people will creating them everytime using an `async` without understand the cost.

Those languages often also have Promises, or Futures, or Tasks, or one
of the other closely-related names and concepts.

~TJ