Hacker News Reader

Comment by modarts | Hacker News Reader

What's wrong with async/await?

Even as a huge async/await fan, this is a great explanation of the problem: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

VMs that offer lightweight, blocking, non-shared memory, threads provide a great developer experience. The Dart team was experimenting with this with the Fletch VM.

When calling a function, you know what arguments/parameters to use, right!? Then you also know if it's sync or async. The browsers way of dealing with async seems to be forgotten, for example:

  button.onclick = buttonClicked;

I find this pattern easier to deal with then callbacks.

While it gives good insight to the problem of sync vs async functions, I've come to find its conclusions problematic (and it rather blatantly ignores Chesterton's fence), especially with "Java did it right, but they have started to do it badly now", and especially "Go has eliminated the distinction between synchronous and asynchronous code". Ouch. You are going to think that - until your hit first deadlock or race condition.

While implementation quality of the "colored function" concept varies greatly (and JS async/await is not a good example IMO - look at C# for one that doesn't neccesarily suffer the "async all the way up" problem, for example), there are reasons it's so prevalent. Async is fundamentally different, and more importantly: In the end, it's all about the data.

That's why the most important part of goroutines is the channel/send/receive(EDIT: And especially select, of course. :)) implementation. And that's why the simple "go func" syntax itself or whether it's different from normal function is a bit of a red herring, since the implementation and data access/communication inside the function will likely be different.

I don't know why you're getting downvoted, you're right.

I love Go, it's my language of choice. There's a clear difference between calling a function sync or async. It's nice that we can choose to do either at will.

Oh, except that if it's an async call we have to use channels to communicate with it. Which is cool, but it's a different mechanism than if it's a sync call.

It's exactly the same as the red/blue rant about JS. If it's async you have to hand it a channel to talk to you on. If it's sync you can just wait for it to return. Async/Await same same but different.

Yes, the language does some nice stuff under the covers about pausing goroutines, but it only does that if you have multiple goroutines. If you code everything without using goroutines (and channels) then it's not concurrent and won't do the nice stuff. It'll pause for i/o just like any other language.

While I don't use async / await right now, mostly because it's not natively available in all of the target browsers I want to use, I'm not the biggest fan of the pattern. It takes previously asynchronous functions and makes them appear as synchronous. The worst part is with some asynchronous methods you can't use async / await so now you have synchronous and asynchronous code that appears identical while also having some other asynchronous code that appears more traditional.

Overall it just ends up being a bit inconsistent for my tastes. But I like that we're trying more things to evolve the language to avoid common pitfalls like callback hell

It's funny watching part of the history of C# replay itself in Js, I heard the same arguments when it was playing out in C# (TPL => Promises, await/async => await/async)

It's a kludge. Syntactic sugar to remove one level of nesting.

Other languages come either with great concurrency support out of the box (Go, Erlang) or enough constructs to implement cooperative schedulers without having to specify async/await (Lua).

What's wrong with that?

Not disagreeing, but as a long time JavaScripter it is remarkable to me that no matter how delightful or expressive or ergonomic the language tries to become, the same old criticisms manage to evolve with it (this may not be unique to JS).

[Edit] JS has long been criticized (fairly or not) for offering clunky "concurrency" strategies. If you must down vote, please have the decency to offer a counter perspective.

As someone who has been around for a long time and manages teams using many different languages (C,C++,C#,Java,Python,JavaScript) my JavaScript/Web teams are the most problematic in terms of cost/performance/gating bugs/upgrades/multi-platform support. The JavaScript critiques that you see are just an expression of the time and resources being wasted.

Where in the stack did you spend your time before you became a manager?

If you have callbacks, you end up with hard to read and debug code.

If you have transparent async, then:

Then how do you know what blocks and what doesn't ? What's asynchronous and what's going to trigger a switch ? What's a disguised callback and what's the next line ?

What's the solution then ?

Why would you need to know, except in some special cases? If you're using async/await, your next line is not executing anyway until the result comes, blocking or not.

Because otherwise you block the even loop or mismatch life cycle. Espacially reading an unfamiliar code base.

embrace higher-order functions. Use named functions and closures!

example code:

  var anchors = document.getElementsByTagName(“a”);
  for(var i=0,len=anchors.length; i<len; i++){
    alertClickAnchor(i); // Named function
  }

  function alertClickAnchor(i) { // Closure
    anchors[i].onclick = function() {
      alert(i);
    }
  }

This makes anything but basic life cycles very hard to read.

You can look at each function at a time and only have to understand what that function does. No more nesting.

2 main reasons: 1. If some nested function is async/await, all the callers (and whole graph) need to be converted to async/await. I feel that language shouldn't force programmer to do this type of tedious work. 2. It's not compatible with some browsers, only via Babel

#1 is a misleading claim. An async function returns a promise when called, which can be used in any non-async context.

I think the claim was: One async function (which of course returns a Promise under the hood) forces all surrounding functions to be also asynchronous (return a promise). Of course you could start an async operation from any function -> Just call the async function and ignore the result. But in order to do something with the result and return a transformed version of it the surrounding function has to be async (return a Promise, accept callbacks, etc) too.

Maybe the confusion was the async here has two meanings:

1. asynchronous in general, which means it doesn't return a result immediately, but returns it through a Promise which is fulfilled later or a callback.

2. Using the async/await syntax. As we all agree this one is just sugar around Promises.

In JS async/await returns a promise. In Python you have asyncio.ensure_future() to schedule coroutines. You can always call async code from sync code.

> If some nested function is async/await, all the callers (and whole graph) need to be converted to async/await

Is totally false. You can await on any promise, the method called doesn't have to be an async function.

And you can resolve any async function through promises as well.

> 2. It's not compatible with some browsers, only via Babel

async/await is part of the the ES spec, which browsers have to follow to be compliant with ES spec.

Reply on news.ycombinator.com