[mrozbarry]

My biggest gripe with async await is when it's used by people that don't understand promises. They interpret await as "let promise run" and not "this blocks the flow." I had someone show me code where they wanted to preload a bunch of images, and effectively had a for loop and did an await on each image in it, effectively running it as slow as possible. I showed him `await Promise.all(imageLoadingPromises)`, and he was confused why we needed `Promise.all` here.

I also don't like how async/await ends up taking over a whole codebase. Often making one function async will cause you to update other functions to be async so you can do proper awaiting. We literally exchanged callback hell to async hell, and said it was better, but I'm not strictly convinced of this.

[spankalee]

It's not async/await that takes over a codebase, it's the async nature of functions period, no matter if you're using async/await, Promises, or callbacks.

Callbacks still have the function coloring problem: If you write a function which calls another function with an on-complete callback argument, then your function (usually) has to also take an on-complete callback in order to represent completion.

async/await makes this nicer, but it doesn't eliminate the underlying need to thread async completion all the way up your call stack.

[throwitaway1123]

> I also don't like how async/await ends up taking over a whole codebase. Often making one function async will cause you to update other functions to be async so you can do proper awaiting.

This is basically the function coloring problem. There was some ardent discussion about this a few weeks ago on HN [1], where the top comment positioned function coloring as a feature, because it highlights where expensive operations like IO might potentially be happening in your application.

I saw a comment recently where someone pointed out an old API in Java where comparing two URLs for equality initiates a DNS request, and so something as simple as putting a URL in a hash table could end up involving a network request [2]. So maybe it's reasonable to color functions that connect to the network at the very least. If I used a URL comparison library and it returned a promise it would immediately set off alarms in my mind.

[1] https://news.ycombinator.com/item?id=41001951

[2] https://news.ycombinator.com/item?id=41143458

[phyrex]

That could be much better solved through coeffects, but unfortunately most languages don’t support that. Doesn’t mean using async functions is a good way for this either

[throwitaway1123]

> That could be much better solved through coeffects

It's possible, but I can't thoroughly evaluate coeffects until they land in a mainstream language with production usage. What I do know from experience is that you can't quietly block the entire thread on a network request in some innocuous looking function in JS. You have to return a promise and then the calling function has the option to await that promise, but I'm sure the academics in their ivory towers have theorized about something better.

[phyrex]

It doesn't quite fit your requirements, but Facebook's PHP variant has an effects system like that which they use: https://docs.hhvm.com/hack/contexts-and-capabilities/introdu...

[throwitaway1123]

This looks pretty cool. One issue I have from just a cursory glance is that the IO capability includes things like `print` and `echo` [1]. If the context system can't differentiate between `console.log` and `fetch`, then it's a little less useful for me.

If there was a way for users to define their own coeffects then you could sidestep this issue, but I saw this quote in one of the design documents: "Runtime will have a native knowledge of each co-effect. We will not allow co-effects to be defined in user-land code [...] An important aspect to note here is that certain co-effects that need deep support from runtime such as io and pure will need to be implemented in the runtime" [2].

[1] https://docs.hhvm.com/hack/contexts-and-capabilities/availab...

[2] https://github.com/facebook/hhvm/blob/master/hphp/hack/doc/H...

[phyrex]

Hack is custom made for facebook and its use cases, and there’s no use for distinguishing those kind of IO at Facebook. The main use case for the effects system is actually privacy, wherein where processes that aren’t privacy controlled cannot access user data or data that got processed by other functions that did. And that’s enforced by the runtime. It’s super cool and a great example of what those systems are capable of.

[lofenfew]

>We literally exchanged callback hell to async hell, and said it was better, but I'm not strictly convinced of this.

It's obviously better. It's a bit unfortunate how much the history of the design decision shines through in the current solution, but it's unequivocally an improvement.

I would prefer an approach where calls to "async" functions are implicitly awaited unless a keyword turns then into a promise, and all functions are implictly treated as async as needed, unless a keyword specifies that they return a promise, which should be awaited instead. This would make the majority case clearer, and force you to make the minority case explicit where it's currently implicit.

I don't think this would help your coworkers who don't understand promises very much though.

[tyleo]

Chapter 15 of the 2007 release of "Programming Languages: Application and Interpretation" gives a really good motivation for the async/await syntax. Here is a link: https://cs.brown.edu/~sk/Publications/Books/ProgLangs/2007-0...

> I would prefer an approach where calls to "async" functions are implicitly awaited unless a keyword turns then into a promise, and all functions are implictly treated as async as needed, unless a keyword specifies that they return a promise, which should be awaited instead. This would make the majority case clearer, and force you to make the minority case explicit where it's currently implicit.

This is a very interesting idea and feels good in an initial 'gut check' sense.

[felixfbecker]

That's basically how goroutines work in Go. You opt into concurrency with the `go` keyword, while it's blocking by default. While in JS it's concurrent by default and you opt-in to blocking with the `await` keyword. (Except in Go you have true parallelism for CPU-bound tasks too, while in JS it's only for I/O)

Both have their pros and cons. I've seen problems in Go codebases where some I/O operation blocks the main thread because it's not obvious through the stack that something _should_ best be run concurrently and it's easy to ignore until it gets worse (at which point it's annoying to debug).

[shivawu]

This is I believe how ziglang works on its asynchronous story

[mrozbarry]

I prefer the raw promise syntax. It makes the promise chain look more like what it is, an asynchronous pipeline, and you don't need to litter async everywhere.

    const myAsyncThing = async (init) => {
      let value = await task1(init);
      value = await task2(value);
      return value;
    }

    const myPromiseThing = (init) => task1(init).then(task2)

I know this is a relatively simple and contrived example, but there are some times where async/await very much is bulky and gets in the way of just writing code.

[THBC]

That’s not ”raw Promise” syntax, that’s Thenable syntax.

Compare with

    const myPromise = new Promise((resolve, reject) => resolve(”foo”));
    

Afterwards either try-catch await myPromise, or use myPromise.then().catch()

[saurik]

I mean, you didn't even try :/.

    const myAsyncThing = async (init) => await task2(await task1(init))

This makes the promise chain look much more like what it is, given that the rest of the language uses nesting calls to indicate "after".

[mrozbarry]

I didn't write it like that because it obscures the call order. I wasn't trying to compare code line/count, just flow control and readability, which is certainly subjective.

[saurik]

If this "obscures the call order" then isn't that a problem with the programming language in general? If these functions weren't async, would you also not be willing to use g(f()), as that "obscures the call order"? (I certainly have met people who do.) If we aren't going to use function calls, and we also do not want to put these functions on separate lines as that is "bulky", then are we going to argue that we should have something similar to .then() for synchronous code?...

My argument here is that JavaScript is -- as well as most languages we use these days are -- fundamentally designed around the syntax of a function call, and so if you program in such for very long at all you get used to reading "inside out, right-to-left", as that's how function calls work. If we do not like inside out execution order, then we should fix the entire language (by using suffix notation... fwiw, I'd be totally on board ;P), rather than narrowly complain about it only in code which uses async/await and fixing it by abusing the OOP this argument exception to the ordering rule.

(I would also point out that the special syntax order exception you are relying on only works for a single argument, and so if you have to pass task2 both the result of task1 and a second argument to configure it, the usage of .then() breaks down unless we have a way to curry arguments, which we can always simulate using JavaScript's bind(), but at some point we are really going far out of our way to avoid coding using function calls, despite being in a language which relies on them everywhere else.)

At the end of the day, I am just looking for some consistency, so I can quickly and easily interpret what code does no matter whether it is synchronous or asynchronous and whether it takes zero, one, or more inputs.

[THBC]

    const value1 = await task1(init);
    const value2 = await task2(value1);

[alemanek]

I love async but very rarely use await. It makes inversion of control patterns super easy and avoids deep logic and instead get something much more readable.

I treat await as a code smell and always triggers me to evaluate if we really need to be waiting for the result in this place. Most of the time they shoukd just return the promise or put something in a then.

People are going to misuse stuff but it doesn’t mean we shouldn’t use appropriate tools when appropriate.

EDIT: this is especially true for NodeJS where lots of frameworks are promise/async aware and support you returning a promise to them.

[WatchDog]

There is zero reason to use async without await, unless I’m missing something.

The number of await calls in your codebase should always be greater than the number of async modifiers.

[alemanek]

Async implicitly wraps the return in a promise if it otherwise wouldn’t return one. Useful for wrapping logic that otherwise would be synchronous. So, syntactic sugar so you don’t have to have “new Promise” to wrap what would otherwise be synchronous logic.

Instead of using await you can instead just use “.then(() => part that needs to wait)”, or a chain of “.then” on the returned promise to sequence dependent logic. Or if needing to wait on a set of async actions you have “Promise.all”. It is much more explicit on what part actually needs to wait instead of “everything after this in the function block”.

I prefer to just compose promises which allows you to sequence actions that need it. It is a code style preference but I find I end up with clearer codebases doing it this way.

[WatchDog]

> Async implicitly wraps the return in a promise

Yes. Without using await, it's basically the same thing as just changing `return result` to `return Promise.resolve(result)`.

> Useful for wrapping logic that otherwise would be synchronous.

The logic is still synchronous, except now the return value is just wrapped in a promise.

> Instead of using await you can instead just use “.then(() => part that needs to wait)”

I don't understand why this would ever be desirable versus just calling the function synchronously. If for some reason you really need `.then` I would just wrap the call to the function, instead of making the fn async, `Promise.resolve(myFn()).then(() => part that needs to wait)`

> if needing to wait on a set of async actions you have “Promise.all”.

You can pass non-promise values to `Promise.all`, and it will work fine, although I don't see why you would do it intentionally. ie `await Promise.all([1, Promise.resolve(2)])// resolves to [1,2]`.

> It is much more explicit on what part actually needs to wait

If anything it's less explicit, you are disguising the true behavior. You making a synchronous function look like it's async when it isn't.

It's also going to suffer a small performance penalty, although it shouldn't really matter unless the function is used in some tight loop. When I tested calling a very simple `return 1` function, making it async resulted in the benchmark taking twice as long.

[craftkiller]

> They interpret await as "let promise run"

This is actually how rust handles async/await. If nothing is polling the future then the future is not running. If you want background execution like javascript then you need to hand it off to an executor (for example via `tokio::spawn`). Its actually pretty nice because then you can build a future and pass it around but you can decide if/when you want to execute it later.

That being said, you still wouldn't want to do a for loop awaiting each future.

[kccqzy]

I agree. People should gradually build up their intuition from lower abstractions to higher. People should be banned from using async/await unless they had first experienced callback-based code, and then promise-based code. Going straight to async code is like asking people to run before they have learned to walk.

[rileymat2]

It is not clear to me where you stop the tunneling down the abstractions. It seems arbitrary to each person to their knowledge base.

I have a degree in Electrical Engineering, and don't understand how programmers can function not understanding physical computer architecture.

But clearly, that's not the bar which most come from.

[THBC]

What? In JS async/await is _literally_ syntactic sugar for returning/thening promises.

[kccqzy]

They need to have experience and intuition working with promises without syntactic sugar, before being allowed to use syntactic sugar.

It's a basic way to learn. In Python you don't directly teach people about decorators without first asking them to explicitly reassign a function to the result of calling the decorator. In Haskell you don't teach people about do notation without first making them write nomadic code with the bind operator and many lambdas.

In many cases, just a few days of forbidding students to use the syntactic sugar is enough to make them appreciate why this syntactic sugar is needed and how it is supposed to be used. JavaScript's async/await is the same.

[moralestapia]

Can you give a concrete example of "async hell"?