Async/Await will make code simpler
blog.patricktriest.com
Async/Await will make code simpler
1–10 of 93 posts
Re: Async/Await will make code simpler
#2I 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).
Re: Async/Await will make code simpler
#3same example with async control flow library and node style callback conventions
function getUserInfo(callback) { async.parallel([api.getUser, api.getFriends, api.getPhoto], callback) }
Re: Async/Await will make code simpler
#4Though the article doesn't mention it, the "alternative" is Reactive programming (via RxJS) I think for the typical UI application developer, async / await can provide easier readability and debugging, but at the cost of some expressive power and conciseness.
Now that chrome supports async / await in the debugger, it's almost certainly the best choice, compared to promises and callbacks.
In the redux world, you can see this by comparing redux-observable [1] (reactive / rxjs) with redux-saga [2] (generators)
Rxjs requires a deeper understanding of Reactive programming. Once you understand it, you can write very powerful expressions in a few lines. But debugging is tough and it doesn't translate well for your fellow developers.
Re: Async/Await will make code simpler
#5I 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/archi…
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).
Re: Async/Await will make code simpler
#6Anyone else bothered by the utter lack of semicolons in the example code? :D
Re: Async/Await will make code simpler
#7I 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/archi…
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 po…
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.
Re: Async/Await will make code simpler
#8I 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/archi…
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 po…
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...
Re: Async/Await will make code simpler
#9Though the article doesn't mention it, the "alternative" is Reactive programming (via RxJS) I think for the typical UI application developer, async / await can provide easier readability and debugging, but at the cost of some expressive power and conciseness. Now that chrome supports async / await in the debugger, it's almost certainly the best choice, compared to promises and callbacks. In the redux world, you can s…
Only downside I've found with this is that Observables feel like more of a pain to test, since your logic gets more tightly coupled to your I/O. Or at least there's more complexity involved in the relationship between I/O and data manipulation. I used them for a Node project via RxJS and ended up just switching back to promises, as it wasn't complex enough of a project to really see much of a benefit from Observables.
Re: Async/Await will make code simpler
#10Earlier quoted context omitted.
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 po…
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.