I've decided that my Future::AsyncAwait CPAN module is sufficiently non-alpha that I've started migrating a few of my less critical code into using it. I thought I'd pick a few of the Device::Chip drivers for various kinds of chip, because they're unlikely to be particularly involved in anyone's real deployment code, as really I only wrote those to test out some ideas on the chips before writing microcontroller code in C for them. These seemed like good candidates to begin with.
Here's an example of a function in the previous version, using Futures directly. The code had lots of syntactical noise, some ->then chaining and the Future::Utils::repeat loop not looking like a regular foreach loop. You can just-about read what's going on but it's clear there's a lot of machinery noise getting in the way of really understanding the code.
By rewriting all the logic using await expressions inside an async sub we arrive at a version that much closer resembles the sort of thing you'd write in straight-line synchronous code. In reading it you can just skim over the awaits while looking at it and read it like synchronous code.
A question you might begin to ask at this point is why I'd choose to implement this particular set of syntax or semantics, of the various possibilities for how to manage asynchronous control flow. Aside from its general neatness and applicability to Futures (which I've already worked with at length), there's one key reason: The async/await syntax here is the exact same thing as implemented in Python 3, ES6, C#5, Dart, even Rust is currently considering adopting it Yes, it's nice to have a good concurrency model built into the language, but it's considerably stronger if it's the same as the consensus among a variety of other languages too.
Some language references for them:
| Python | Tasks and coroutines |
| JavaScript | async function |
| C# | Asynchronous Programming |
| Dart | Dart Language Asynchrony Support |
If the four quite semantically-different languages of Python, JavaScript, C# and Dart can all come to the same idea, then maybe it has merit. I honestly think that given a few years, async/await could become as ubiquitous as if or while loops, to the level of "well obviously our language has that". This is why I wanted to steal it into Perl. In ten years time it might look as foolish for a language not to have an async/await construct, as it does today for it not to have a try/catch or a switch.
Ah... more on that subject another day perhaps ;)
As a developer that has used IO::Async a fair bit for production use as well as JavaScript Promises a bunch, I've come to really like async & await syntax in JavaScript as opposed to ->then and ->catch syntax.
ReplyDeleteWhich is to say, thanks! This looks awesome and will make coaching developers who don't specialize in perl a lot easier.
Hi Paul, I'm a big fan of your work on Futures and Async/Await in Perl. I've used it with mostly success to build a service that spawns threads and processes data concurrently.
ReplyDeleteI've run into an issue tho, where the futures from async/await are lost "[func] lost its returning future". I'm getting familiar with 'retain_future" but I do not see a way to get this working with async/await. Are there other tricks to ensure the future from an async function is not lost?