I go back and forth on async/await. On the one hand, it is utterly brilliant. On the other hand, it seems like the final epicycle, trying to fit a theory of circular geocentric orbits (call/return) onto a real world of elliptical heliocentric ones (asynchronous programming).
So yes, it will make code easier, but I fear that will only serve to prolong the dominance of what is arguably the wrong programming model/architectural style. Or more precisely: an insufficient programming model/architectural style (it is great for a lot of things, just not for all).
The way I look at it is as just another way of manipulating continuations, alongside conditional, loops, call/return, generators, coroutines, exceptions, etc. Even in some other hypothetical asynchronous paradigm, all those patterns still occur all over the place, so making them all composable with each other is a win. (Credit to http://blog.paralleluniverse.co/2015/08/07/scoped-continuati... for describing it this way.)
The surface syntax could maybe use some work- maybe make functions generic across asynchronicity, maybe swap `await` to being the default and explicitly mark the case where you want a reified Promise instead, etc. But in the end it's another valuable control structure.
await/promises/etc mostly exist to solve the problem that JavaScript doesn't have threads so it can't wait for callbacks.
About JavaScript, many other languages have had async/await for a long time. I have no idea why JS made such a huge deal of promises, I guess they're better than the callback hell before. Of course, in most languages using async isn't nearly as important for performance because they have thread pools.
Some interfaces aren't and won't be asynchronous (like Linux file IO) so eventually JS will support proper threads and we can stop talking about how great asynchronous programming is (it isn't).
Maybe promises come before async/await, in an evolutionary sense. Same way that for-each loops seem to precede generators / yield. C# added Task before the syntax sugar of async/await. Java currently has Future, and I expect async/await to finally show up in about 10 years time...
Just wanted to write that ;). Despite being C# developer and often smiling at the state of the Java language, I think Java will get async/await faster than in 10 years. I am more optimistic about it.
Node has threads in C++ for that sort of thing. Async programming is a big deal for performance. That's essentially the main reason Node is any faster than Python. If you use fully async Python on uvloop, you can get comparable performance.
It is ultimately a failure of language and runtime that programmer has to manually specify where he wants to make asynchronous vs. synchronous functions to get the optimal performance.
> that programmer has to manually specify where he wants to make asynchronous vs. synchronous functions to get the optimal performance.
programs aren't just pure computations. There are plenty of times when you want a specific event to happen at a specific time (as in, wall-clock), and plenty of times when you don't care when something computes as long as you end up getting a result at some point.
You don't get reliable wall clock time unless you're working in RTOS. In a threaded OS everything in userland is async to an extent. In this school of thought, having to specify that something should be async manually could be seen as a failure of the language.
>So yes, it will make code easier, but I fear that will only serve to prolong the dominance of what is arguably the wrong programming model/architectural style.
Nested callbacks and even Promises are not the "right model/style" by any measure. Even 30+ year old languages had better answers to asynchronous programming than that.
Nested callbacks is so backwards its like writing in assembly. Only people whose first exposure to asynchronous programming was Node think it's a valid programming style.
> Nested callbacks is so backwards its like writing in assembly. Only people whose first exposure to asynchronous programming was Node think it's a valid programming style.
It depends on precisely what structures you include in your definition of "nested callbacks" here. I think that the callback and errback chains on the Deferred object in Twisted is basically the perfect abstraction for the flow control they represent.
So yes, it will make code easier, but I fear that will only serve to prolong the dominance of what is arguably the wrong programming model/architectural style. Or more precisely: an insufficient programming model/architectural style (it is great for a lot of things, just not for all).