thePoint.md

In other words, the following asynchronous code:

var d = Domain.create()

d.on("error", function (error) {
    console.error("Error with the twitterverse:", error)
})

d.enter()

getTweetsFor("domenic")
    .reduce(findMostMentioned, [])
    .map(function (mostMentioned) {
        return mostMentioned.map(function (user) { return user.username })
    })
    .toArray(function (mostMentionedNames) {
        console.log("Most mentioned names:", mostMentionedNames)
    })

d.exit()

parallels the synchronous code:

try {
    var mostMentioned = findMostMentioned(getTweetsFor("domenic"))
    var mostMentionedNames = mostMentioned.map(function (user) { return user.username })
    console.log("Most mentioned names:", mostMentionedNames)
} catch (error) {
    console.error("Error with the twitterverse: ", error)
}

Note in particular how errors flowed from any step in the process to our catch handler, without explicit by-hand bubbling code.

I still maintain that you have a hammer and all you see are nails. (In this analogy, promises are a screwdriver. Both can useful for building things but nailing screws into the wall is ignoring the benefits of having them securely screwed.)

That's pretty much Rx vs TPL in .NET world. I use them both happily.

Promises don't enable anything new. They might be better for some developers. The pseudo-comp-sci arguments are fatuous. AOP can also be wrapped in very sexy theory about how some "rules of ideal programming" are now being properly followed, as you can do with message passing languages, and many other language types. All mothers think their baby is the cutest.

Frankly, the main concern of modern software (and hardware) is dealing with concurrency (and indeterminacy), and the Promise spec doesn't impress in terms of innovation or sophistication. As mentioned, evented stream processors are much more interesting and flexible -- really, infinitely flexible.