Why no Future support?

[shadowcat-mst]

The Moo community and assorted people have been working with Future.pm for building highly parallel code for some time, and it's proven a pragmatic API that's basically 'Promises without the bureaucracy and pointless CS posturing'.

While I understand the desire to support multiple event loops, Future.pm is already built to do so and has been in production for us for longer than the Promises module has been on CPAN.

I'd much prefer to use tried and tested code - is there any chance of allowing support for doing so as well as using the super-abstract API of Promises for people wanting javascript compatibility?

[clintongormley]

Hi Matt

I'm open to supporting Futures. When I compared Futures with Promises, I much preferred Promises. I found the API to be a lot cleaner and more intuitive (at least for me). I also ended up rewriting half of it to make it conform to Promises A+.

What I'm lacking is time... Elastic::Model really needs upgrading soon - users are getting annoyed :)

So there are a few possibilities:

1. I'll happily accept a patch implementing Futures, should just be a case of copying the Promises implementation.
2. It'd be reasonably easy to provide a Futures wrapper of the existing Promises implementation (really just some methods in *::Transport and Scroll and Bulk modules), the downside being that there are two frameworks interacting.
3. Wait until I have more time :)

[shadowcat-mst]

On Tue, May 13, 2014 at 11:40:12AM -0700, Clinton Gormley wrote:

Hi Matt

I'm open to supporting Futures. When I compared Futures with Promises, I much preferred Promises. I found the API to be a lot cleaner and more intuitive (at least for me). I also ended up rewriting half of it to make it conform to Promises A+.

In real world use I've found the simplicity and directness of futures makes
them far less irritating to debug.

This is of course, a personal opinion, hence why I'm thinking "both" would
be nice - especially since we're working slowly towards IO::Async support in
Catalyst so being able to interact with the async layer properly would likely
be rather helpful (for values of "we're" meaning "I keep tricking people
working on the two into collaborating", as usual :)

1. I'll happily accept a patch implementing Futures, should just be a case of copying the Promises implementation.
2. It'd be reasonably easy to provide a Futures wrapper of the existing Promises implementation (really just some methods in *::Transport and Scroll and Bulk modules), the downside being that there are two frameworks interacting.

I'm fairly sure either of these should be pretty doable. I'll see if I can
scare up somebody who cares.

If I can't, then presumably nobody cares that much and the "patches welcome"
offer can remain open while you hack on more pressing things.

Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

[clintongormley]

Splendid.

[clintongormley]

Btw, one alternative is just to make Promises play nicely with Futures. Then the whole discussion is moot. Promises already accepts any "then'able" object, but I think work would need to be done on the Futures side.

[shadowcat-mst]

On Tue, May 13, 2014 at 11:51:37AM -0700, Clinton Gormley wrote:

Btw, one alternative is just to make Promises play nicely with Futures. Then the whole discussion is moot. Promises already accepts any "then'able" object, but I think work would need to be done on the Futures side.

Stevan keeps insisting they're for separate things so that doesn't make
sense, and I've yet to be able to understand why sufficiently well to figure
out what rathole I'd be walking into if I tried to do it anyway.

Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.

[clintongormley]

@stevan - care to comment on the above?

[stevan]

@shadowcat-mst no, you've misunderstood my position re: Futures/Promises. Promises.pm and Futures.pm are fairly similar to one another in intent, where they differ is mostly in the API.

Promises.pm uses the minimalist approach of Promises/A+ spec (which obviously @clintongormley and I both prefer) it pretty much does one thing and one thing only. Whereas Futures.pm has a very much un-minimalist API which is somewhat more akin to the Combinator approach that you find in the Scala/Akka Futures implementation.

The Futures combinator style API could very easily be built on top of Promises, which is something I have stated to Paul Evens several times. Additionally, as @clintongormley suggested, I highly suspect Promises could play well with Futures since both are event loop agnostic and (I assume) are not overly promiscuous with Perl internals in a not nice way.

As for relative maturity, I agree, Futures has had more battle testing in production (I never managed to get Promises into production before the project it was for got cancelled), but Promises is built to adhere to the Promises/A+ spec which has been through the ringer in the Javascript community for a while now. So while Promises might not have as much exposure in the wild, it is built on a solid theoretical foundation (cough like Moose, and many of my other modules cough).

[clintongormley]

Inactive, closing