Promise.cast and Promise.resolve

Kris Kowal kris.kowal at
Tue Jan 28 20:12:39 PST 2014

In this case, a half pursuit of type purity is a side quest at the expense
of users. Having two ways to resolve and two ways to observe a promise is
unnecessarily confusing. In my experience, one method like "then", that
unwraps recursively, and one function, like "Promise.cast", that
automatically lifts if necessary, and "then" handlers that return into the
waiting hands of "Promise.cast" are coherent and ergonomic. Having a choice
between "cast" and "resolve" and a choice between "then" and "chain", will
leave developers unnecessarily confused and worried all the while they use
or abandon Promises as too subtle.

For quite some time, grammarians have been losing a war to impose Latin
purity on English, in the case of split infinitives. Not long ago, the
famous phrase, "to boldly go", were a racy departure from convention
because in Latin, the infinitive verb "to go", is a single word, and you
simply would not break the word in half to put a poetic adverb between the
syllables. English is not Latin, and JavaScript is not Haskell.

Auto-lifting/unwrapping promises are beautiful. Purely monadic promises are
beautifully captured by type theory. But, I would pick one or the other
over one with multiple personalities. I would pick "Promise.cast" and
"then", let complexity melt off the spec, and stop worrying.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list