Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Async/Await will make code simpler

blog.patricktriest.com

Post reply on HN
Print view View original

31–40 of 93 posts

Re: Async/Await will make code simpler

#31

Post by coldtea »

mpweiher wrote: post #2

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/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 exposure to asynchronous programming was Node think it's a valid programming style.

Re: Async/Await will make code simpler

#32

Post by jcelerier »

balfirevic wrote: post #13
jrs95 wrote: post #7

Earlier quoted context omitted.

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. 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.

Re: Async/Await will make code simpler

#33

Post by coldtea »

jrs95 wrote: post #7
throwasehasdwi wrote: post #5

Earlier 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.

>That's essentially the main reason Node is any faster than Python.

v8's JIT is many times faster than Python in CPU bound tasks without any asynchronicity involved.

Re: Async/Await will make code simpler

#35

Post by jMyles »

zackify wrote: post #27
dlbucci wrote: post #22

I was super excited about async/await when it first came out. I hadn't really understood the point of Promises, but async/await looked simple and useful. However, I recently started using async/await in TypeScript, and the result seems to be try/catch statements everywhere. Code using async/await seems to be more verbose and unruly than just sticking to Promises, which I now appreciate the elegance of much more (call…

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?

Re: Async/Await will make code simpler

#36

Post by samblr »

askmike wrote: post #14
hitgeek wrote: post #3

same example with async control flow library and node style callback conventions function getUserInfo(callback) { async.parallel([api.getUser, api.getFriends, api.getPhoto], callback) }

Even with a library like async there will be so much boilerplate, since you need to handle (or pass) errors every step of the way. With async/await you only need to deal with errors at the level you actually care about them (using the language build in try/catch block).

Agreed there there is boiler plate - but with use of live templates in webstorm (or snippet in VS) - I find it getting easier.

Re: Async/Await will make code simpler

#37

Post by treve »

dlbucci wrote: post #22

I was super excited about async/await when it first came out. I hadn't really understood the point of Promises, but async/await looked simple and useful. However, I recently started using async/await in TypeScript, and the result seems to be try/catch statements everywhere. Code using async/await seems to be more verbose and unruly than just sticking to Promises, which I now appreciate the elegance of much more (call…

This makes little sense. You don't need more try..catch blocks than you would normally have a catch promise clause.

Exceptions bubble up.

Re: Async/Await will make code simpler

#38

Post by raquo »

dlbucci wrote: post #22

I was super excited about async/await when it first came out. I hadn't really understood the point of Promises, but async/await looked simple and useful. However, I recently started using async/await in TypeScript, and the result seems to be try/catch statements everywhere. Code using async/await seems to be more verbose and unruly than just sticking to Promises, which I now appreciate the elegance of much more (call…

hmm were you previously using Promise.catch for flow control? It's basically as bad as using exceptions for flow control, just with with a different set of bubbling / propagation problems. Unless you're dealing with truly exceptional conditions you should not be throwing inside your promises, thus no need for try / catch when converting them to async/await.

Re: Async/Await will make code simpler

#39

Post by Bahamut »

askAwayMan wrote: post #26
imperio59 wrote: post #6

Anyone else bothered by the utter lack of semicolons in the example code? :D

If you've got a halfway decent linter, semicolons are just clutter. https://eslint.org/docs/rules/no-unexpected-multiline is the sort of thing that makes semicolon free style practical.

There is one situation where semicolons are important - when concatenating multiple script files & using IIFEs.

This subtlety is being obsoleted by ES modules & the build tooling around them, but it is a nasty bug that has sucked many an hour away from frontend devs whenever it is encountered.

Re: Async/Await will make code simpler

#40

Post by sharemywin »

pier25 wrote: post #28
dlbucci wrote: post #22

I was super excited about async/await when it first came out. I hadn't really understood the point of Promises, but async/await looked simple and useful. However, I recently started using async/await in TypeScript, and the result seems to be try/catch statements everywhere. Code using async/await seems to be more verbose and unruly than just sticking to Promises, which I now appreciate the elegance of much more (call…

I'd rather user try/catch than endless chains of then().

andThen()...andThen()...andThen().andThen().andThen();
Post reply on HN