Does async/await solve a real problem?

Bruno Jouhier bjouhier at
Thu Sep 11 13:41:08 PDT 2014

I'd like to inject my own experience into this discussion.

I am the author of streamline.js, a smalll extension to JavaScript which
adds async/await semantics to the language. I developed this language
extension in January 2011 and we have been using it since then in a large
project (new web stack for a commercial ERP product). Before, in the early
days of the project, we had been using raw callbacks and promise libraries.

The syntax of streamline.js is different from async/await but the semantics
are aligned. The marker is different (_ instead of await) but it is
explicit at all levels. Parallelism is achieved with futures, which are
just simplified promises (the language was made promise friendly recently).

My experience is that async/await makes a huge difference for large
projects with a lot of logic sitting on top of async APIs. More

   - Productivity: developers write code faster and they write less code.
   - Maintainability: code is easier to read and understand. Control flow
   is not disrupted by callbacks. Refactoring and modification are easy.
   - Robustness: Error handling, resource cleanup and invariant restoring
   can be done in a simple and reliable way with.well known constructs
   (try/catch and try/finally). Developers don't make silly mistakes like
   forgetting a callback or calling it twice.
   - Learnability: developers coming from other languages (Java, C#) can be
   brought up to speed quickly.
   - Comprehensive parallelization: async/await blends well with
   futures/promises. Concurrency problems are easy to analyze because control
   flow is natural and the  markers highlight all the points where the flow
   may yield control.
   - TLS support: makes it easy to maintain a localization/security context
   across async calls.

So, from my experience, async/await is an absolute must for projects like

On the syntax side, I am not convinced by the await construct. The problem
is that await is prefix. So it does not play well in chains of async calls.
Consider the following:

   - streamline: f1(_).f2(_).f3(_)
   - async/await: await (await (await f1()).f2()).f3();

I'm not particularly attached to the streamline syntax (reserving an
identifier was an easy way to remain compatible with existing language
tools: editors, linters, syntax coloring, ...). I would rather go with
something like the infix ! proposal of

I think that Mark Miller nails it really well:

> The cost of making atomicity cheap is that interleaving points must be
> made explicit. With callbacks, this cost is quite high. Promises reduce
> this cost substantially. async/await further reduces this cost about as far
> as it can be reduced, while still leaving an explicit marker.

IMO promises are only a step forwards; async/await is a leap forwards.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list