Not a gigantic fan of async/await for the reasons that others have mentioned here, but that said it provides the only sane out-of-the-box way for JS to handle loops that contain callbacks/promises.
Async/Await will make code simpler
41–50 of 93 posts
Re: Async/Await will make code simpler
#42I really don't see the need for such a syntax. If I say: Foo foo = someFoo(); ... String content = foo.getContent(); I really don't care if foo was returned when I called someFoo(), I only care that getContent() is not attempted until after foo is defined. There's little reason for me - in this situation at least - to need this async functionality to be explicitly stated. The biggest problem I see is a when you use t…
You may not care, but the computer does!
Re: Async/Await will make code simpler
#43Earlier quoted context omitted.
You can abstract your try / catch logic to a higher level to fix this easily. make all promises extend from a base promise function that either returns a result, or null (or an error, you can make it more complex). Then, let data = await customPromise() if(!data) return this would be better in my opinion that try catch everywhere. Inside that higher order promise you can catch and handle errors.
This sounds confounding to me as a reader - you're telling me that exceptions will intentionally be handled further from where they're raised?
That is the benefit of exceptions over return values as usual in C.
Re: Async/Await will make code simpler
#44I heard Doug Crockford talk about how he doesn't think async/await is that great an idea on a podcast a while ago. His argument was that it's an unclean abstraction - it gives you access to 'features' of synchronous imperative syntax (lines in a function always execute in order, try-catch blocks, etc) but it remains conceptually and literally promises all the way down. Therefore, all await 'calls' are really non-bloc…
Here's a great article somebody posted on HN awhile back, "What Color is Your Function?" -- http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... The proper abstraction is threads--i.e. a stack structure used for the storage of temporary values, which is shared by nested function invocations as well as similar structured programming constructs like if/else conditionals that together represent a singular thr…
I feel the conclusions of that article were pretty spot on. Having done a bunch of async programming in Go, and now picking up Node on the side, I can't help but agree that Go got this right. You have the simplest conceptual model (a synchronous one), with the runtime responsible for making it all run async. JS certainly seems to have come a long way, but it feels like the next step will be the most difficult one, requiring a serious redesign of the runtime itself.
Re: Async/Await will make code simpler
#45I much prefer observables to tasks...
Re: Async/Await will make code simpler
#46Earlier quoted context omitted.
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. This blog posts elaborates on that better then I could do here, so I'm just going to link to it: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
> 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.
Re: Async/Await will make code simpler
#47Earlier quoted context omitted.
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. This blog posts elaborates on that better then I could do here, so I'm just going to link to it: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
> 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.
Yes, but that should be call-time distinction, not a function declaration distinction. This is briefly mentioned at the end of the linked article.
Edit: as other poster mentioned, async/await and promises also don't help with precise wall-clock time but that is entirely different matter.
Re: Async/Await will make code simpler
#48I 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…
> 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 ex…
> 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.
Re: Async/Await will make code simpler
#49I really don't see the need for such a syntax. If I say: Foo foo = someFoo(); ... String content = foo.getContent(); I really don't care if foo was returned when I called someFoo(), I only care that getContent() is not attempted until after foo is defined. There's little reason for me - in this situation at least - to need this async functionality to be explicitly stated. The biggest problem I see is a when you use t…
You may not care, but the computer does!
Why doesn't the computer do it for me?
Re: Async/Await will make code simpler
#50Earlier 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…
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.
Python also has async/await