I beg to differ ;)

I think the biggest benefit is that your async programming becomes/or looks more sequential/synchroneous which tend to be easier to follow, or in other words less spaghetti-ish.

But, as Agehall pointed out, for that to work properly in the Pike implementation the on_success/on_failure callbacks should be able to return a new future object that would bubble into an evetual chained on_success/on_failure. As the implementation is right now that’s not possible. But there are benefits as it is implemented now nontheless. In the Protocols.HTTP.Promise module I’ve started working on you can do stuff like:

import Protocols.HTTP;

…

Concurrent.Future f1 = Promise.get_url(url1);

Concurrent.Future f2 = Promise.get_url(url2);

Concurrent.Future f3 = Promise.get_url(url3);

// Resolve when all is done or one fails.

Concurrent.Future all = Concurrent.result(({ f1, f2, f3 });

all->on_success(lambda (array(Promise.Success) res) {

  // All three request succeeded

  werror(”URLS: %O\n”, res->url);

})

->on_failure(lambda (Promise.Failure res) {

  werror(”The URL %O failed\n”, res->url);

});

…

Or if you’d want a callback for each individual request

array(Concurrent.Future) each = ({ f1, f2, f3 });

each->on_success(lambda (Promise.Success res) {

  werror(”%O succeeded with status %O\n”, res->url, res->status);

})

->on_failure(lambda (Promise.Failure res) {

  werror(”%O failed with status %O\n”, res->url, res->status);

});

…

To me it’s quite easy to follow what that code does.