Grant Proposal: Future::AsyncAwait

Category: Grants

Comments (11)

I'd first like to speak to the value of this project, as I see it. As someone that loves Perl but has worked in many polyglot companies, one of the things that I constantly hear is 'how crappy Perl's support for asynchronous tasks' is. This is of course not true, there's several great systems for this on CPAN. However in a way the proliferation is confusing to newcomers to the language and makes people think asynchronous support for Perl is something bolted on, perhaps haphazardly, rather than well integrated into the language. I believe this work will go a long way towards solving that perception problem, as well as being of tremendous value in and of itself. I hope it will become a great point of integration between the various existing systems and move us closer together as a community. I am sure it will make it easier for people working in other languages to come to Perl, since they will already be familiar with the syntax and it will make it easier for those already working in Perl to take advantage of writing better asynchronous code, which is rapidly becoming a 'must have' in the programming world. In short, this is not only something I think Perl must have on CPAN, but also something we should consider for core integration as soon as possible.

Secondly, I want to speak to the ability of Paul Evans to complete this work. I've never worked with Paul on a job, but I've seen him over the years on IRC helping people and slowly but surely building up a fantastic portfolio of work on CPAN. He's been working in and with Futures and asynchronous code for many years. Additionally he has the trust and respect of some of Perl's most well known programers. I feel very confident in his estimations and ability.

In short, this is work that needs to be done and Paul Evans has my confidence! Thanks for taking the time to read my comments; feel free to follow up with me on any points raised should questions arise.

John Napiorkowski (JJNAPIORK)

+1, async/await is an extremely useful construct which is widely used in other languages. I look forward to production-ready version of Future::AsyncAwait and I certainly will use it in my code.

IMHO funding its development would be a great use of TPF's money.

This is awesome work that Paul has done so far - well worth the funding!

This would be a killer feature for Perl5, bringing much-needed parity to the existing async module support.

If it also shines a light on some of the murkier parts of the Perl internals, even better.

I'd also mention Paul's technical posts such as as evidence that he can manage a good publicly-available writeup as well as putting the code together in the first place.

Nearly every one of the CPAN distributions I'm personally developing would be simplified by the existence of this module. As such, I'm biased but hugely in favour.

(disclaimer: we are one of the existing clients that Paul mentions, and once this is stable we have every intention of using this module heavily in both our internal and public CPAN code)

+1 to this proposal! Having async/await in perl5 would be awesome!

I strongly support this grant request. Paul does great work and is highly responsive and communicative. This project will greatly benefit the community and Perl as a whole.

Folks, apologies; I think I accidentally deleted 2 real comments when removing the 700+ spam entries that were posted in the past week.

All queued comments have been posted as of this time; if your comment is missing, please re-add it.


Async/Await would be a great addition to the language.
This should get funded.

After finally getting my head around promises in JavaScript it has been a pleasure to be able to use Promises in Perl via Doing the same with async/await will also help me convince other developers at $work that Perl isn't as terrible as the 10+ year old non-strict-single-file-Perl code that they've been hacking on for the last 5 years.

First of all, I want to highly endorse this work and Paul's efforts to do it. This is an important project that Perl sorely needs. That said I do want to ask a few minor conditions on the project to support community funding of it.

This mostly revolves around Paul's use of his own Future stack to accomplish the behavior. This is understandable as with many authors we like to use our own stuff. The problem with Future is that it isn't entirely interoperable with other Promise implementations on CPAN. (Note that he and I have discussed this amicably on #mojo). There does exist a standard for Promise implementations across languages called the Promises/A+ spec ( Future does not conform with that standard (fair, as it predates it) and due to some non-standard behavior as a result it isn't entirely easy for other implementations to conform to his. According to him, there are several methods that must be implemented in the Future way in order for the proposed AsyncAwait mechanism to work. I would ask that if the community were to support his work (and again, I hope we do) that he be asked to follow the Promises/A+ spec in doing so.

If that cannot be reasonably asked for in the time or support amount requested, then I could ask a lesser goal of having him expose his suspend/resume mechanism, the low level guts, in some higher level way so that other Async/Await mechanisms may be built on top of it. Preferably this would be at the perl level though if it must be in the XS level, I won't object too strongly as long as it is usable.

Once again, I want to reiterate that I want to see this grant supported, I just hope that the result is as broadly applicable as possible.

I would ask that if the community were to support his work (and again, I hope we do) that he be asked to follow the Promises/A+ spec in doing so.

That seems like a reasonable request, but I don't think it'd be as effective as it might first sound.

Firstly, I don't believe this is directly possible in Perl without a better definition of, which is required by The footnote brings in a requirement for an "event loop", which is an implementation detail - itself does not require this, and a standard "event loop" or "event loop interface" seems a bit out of scope - look at how much time and effort has gone into getting "a MOP into core"!

Given the existence of modules such as Mojo::Promise::Role::Futurify it seems more likely that Promises/A+-compatible implementations can be built on top of rather than the other way around? There are several features of - for example, support for a distinct "cancelled" state - that are a superset of the Promises/A+ spec. If it's not possible to build the compatibility layer on top of, maybe it'd help to have a clear set of requirements that cannot be fulfilled by the current proposal?

This section of the documentation also seems relevant:

We are, with some differences, following the API spec called "Promise/A" (and the clarification that is called "Promise/A+") which was created by the Node.JS community. This is, for the most part, the same API that is implemented in the latest jQuery and in the YUI Deferred plug-in (though some purists argue that they both go it wrong, google it if you care). We differ in some respects to this spec, mostly because Perl idioms and best practices are not the same as Javascript idioms and best practices. However, the one important difference that should be noted is that "Promise/A+" strongly suggests that the callbacks given to then should be run asynchronously (meaning in the next turn of the event loop). We do not do this by default, because doing so would bind us to a given event loop implementation, which we very much want to avoid.

There are a few other Future/Promises implementations in Perl:

  • Future::Q - a Perl implementation of which is (claimed to be) Promises/A+-compliant
  • AnyEvent::Promise - the then method is only documented to support a single callback
  • AnyEvent::Promises - callbacks can't return AnyEvent::Promises instances directly, since the chaining behaviour means it'll wait for those to be resolved/rejected
  • Evo::Promise::* - mostly builds on other things, but having several different classes here makes it a bit hard to extract a common API

Lastly, the Promises/A+ spec is popular in the JS/ES6 world, but C#'s Task/TaskCompletion is a different beast, as is the shocking mess of C++'s std::future. Python3's equivalent is a superset, but is at least compatible. Scala (and Java) also do their own thing:

(disclaimer: the majority of my CPAN modules have been based on for years, so I know that API far better than the other options)

Sign in to add comment