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

81–90 of 93 posts

Re: Async/Await will make code simpler

#81

Post by atombender »

I wish the await syntax was inverted; instead of waiting for an async function, let all async functions await by default. In other words, I wish this worked:

    let foo = myAsyncFunc()
    foo.bar()
Why? Because that's the common case, and the caller shouldn't care whether the function is async or not. If you have a non-async function that you want to change to be async, or the other way around, then you have to change every single call site.

The case where you want to store a promise or wait on multiple is actually the edge case, and they could have reused "async" here:

    Promise.all([
      async myAsyncFunc(),
      async someOtherAsyncFunc()
    ]);
Bonus functionality: If you do "async foo()" and foo() isn't async, the compiler could still ensure that it provided a promise.

Sadly, it's too late for this, and everyone's code will suffer as a result. It's way too easy to forget to add "await" to an async call, and doing so leads to failures that can be hard to track down.

Re: Async/Await will make code simpler

#82

Post by foota »

jd20 wrote: post #44
wahern wrote: post #20

Earlier quoted context omitted.

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, re…

I'm not fluent in Go but I read this blog post about asynchronicity in Go, https://www.golang-book.com/books/intro/10. Is the idea that Go will be synchronous in calls made with the go keyword only when there's some barrier put in place by a channel?

Re: Async/Await will make code simpler

#83

Post by he0001 »

oaiey wrote: post #10
jdmichal wrote: post #8

Earlier quoted context omitted.

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.

No! Async/await is a horrible construct. Keep it away from Java.

Re: Async/Await will make code simpler

#84

Post by mvindahl »

I really like the succinctness of async/await, and I feel like it's the last step of a long journey. The single threaded callback based style of Javascript has always been a mixed blessing. It has allowed for great performance, and it gives better control that having to juggle threads, but it was all to easy to get into deeply nested callback hell.

If you see design patterns as indicators of language smells -- and it's a useful perspective IMHO -- then in this case callbacks were the smell and the various promise libraries were the design patterns. It's a nice thing that promises and their async/await sugercoating have fairly rapidly made it into the core language.

Now, for the one thing that I don't like about async/await: it's deceivingly simple and it's bound to fool both novice programmers and programmers arriving from threaded languages. If you don't understand the underlying concept of promises, you'll easily end up writing suboptimal code (e.g. executing stuff in sequence which would be better executed in parallel).

Still, a net win.

Re: Async/Await will make code simpler

#85

Post by pythonistic »

foota wrote: post #82
jd20 wrote: post #44

Earlier quoted context omitted.

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, re…

I'm not fluent in Go but I read this blog post about asynchronicity in Go, https://www.golang-book.com/books/intro/10 . Is the idea that Go will be synchronous in calls made with the go keyword only when there's some barrier put in place by a channel?

Only if you create a channel with no buffer: then it becomes blocking send or receive. Go channels block when they have nothing to do, either no room to send anything (in the case of a default channel with no buffer) or nothing to receive (when the channel has no messages).

It's not uncommon to use a select statement to allow work to continue (it may act like a loop) and wait to receive a message on a channel. This is the common pattern for handling timeouts: create a timer goroutine that will wake at a set time and send a message to a timeout channel, keep checking to see if work is done, and if the timer fires then cancel the select with an appropriate message (function call or return an error value).

Re: Async/Await will make code simpler

#86

Post by ngrilly »

aidenn0 wrote: post #74
zzzcpan wrote: post #60

Earlier quoted context omitted.

Here's the thing, if you can call functions that themselves can yield - you are in a shared memory multithreading model, where you can never guarantee for any function not to yield, so you have to use synchronization for that guarantee with all the same issues.

In a cooperative multi-threaded model you can only have data-races at function-call boundaries. For example: `x+=1` can never data-race.

Except if your programming language allows you to override the += operator.

Re: Async/Await will make code simpler

#87

Post by raquo »

lobster_johnson wrote: post #80
raquo wrote: post #38

Earlier quoted context omitted.

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.

Rejection is turned into an exception with "await", though. And rejection is perfectly normal with, say, network I/O.

Well yes, that's a reasonable use case. Personally I'm not convinced that all 4xx responses should be rejections, but regardless of that, you should have about as many `catch` blocks with async-await as you have with promises.

Re: Async/Await will make code simpler

#88

Post by mo_po »

atombender wrote: post #81

I wish the await syntax was inverted; instead of waiting for an async function, let all async functions await by default. In other words, I wish this worked: let foo = myAsyncFunc() foo.bar() Why? Because that's the common case, and the caller shouldn't care whether the function is async or not. If you have a non-async function that you want to change to be async, or the other way around, then you have to change ever…

JavaScript often feels too verbose. That's why I like to use elm whenever it is possible.

Re: Async/Await will make code simpler

#89

Post by billytetrud »

davnicwil wrote: post #12

I 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…

I use the futures from node-fibers all over the place in my backend code. It has possibly only once caused me confusion over something. If you're writing your code right, it shouldn't cause confusion. You don't need to make your code ugly to understand when things are asynchronous.

Re: Async/Await will make code simpler

#90

Post by singularity2001 »

atombender wrote: post #81

I wish the await syntax was inverted; instead of waiting for an async function, let all async functions await by default. In other words, I wish this worked: let foo = myAsyncFunc() foo.bar() Why? Because that's the common case, and the caller shouldn't care whether the function is async or not. If you have a non-async function that you want to change to be async, or the other way around, then you have to change ever…

I wish your comment gets upvoted to national news. Those async antipatterns are worse than the 'goto' statement. Time for programming languages to add the 'async' keyword on the caller side.
Post reply on HN