Ask HN: Why can't await be used from non-async functions?

When you call await the function doesn't necessarily have to be preempted (maybe the async function you called already returned) but if the async function hasn't returned then it has to be.

In most systems like that there is a scheduler that keeps a list of things that are being awaited on and keeps track of which ones are ready to return. When you call await on one function the scheduler looks at that list and chooses an await that is ready to continue and executes it.

Making a function support being paused and resumed requires changes in how the function is run and the data that is maintained while it is executing. In addition to behaving differently than sync functions when they execute, the results are also handled differently. Async functions always return a promise - whether they `return` a literal value, return another promise or throw an exception.

Due to these differences, it makes sense that the special nature of async functions and generators must be declared up-front, with the `async` keyword or `*` for generators. It would be possible to design the language such that the function type was determined by looking at whether it contains `yield` or `await` keywords. Python does this with generator functions. However this makes an important aspect of behavior less explicit.

If that's true, does the "function coloring" problem apply to Promise-based code and callback-based code too? (Talking about JavaScript here)

https://hyperscript.org/

hyperscript does away with the distinction between sync and async code by moving it all to the runtime:

https://hyperscript.org/docs/#async

const a = async () => "hello world"

is the same as

const b = () => Promise.resolve("hello world")

Normal functions can't do that. If they wait for something they block, they can't give control back to the run loop.

In the first case I am telling an executor what it has to do (it has to execute the thing then continue inside my function)

In the second case I am myself blocked into a state that will be unblocked when the thing returns.

That is in the first case my function must be of a type that can be stopped and continued and I need to save its state somewhere.

In the second case I don't need the ability to stop and continue my function.

That makes for two kinds of functions at some level. Low level languages will expose that. High level languages will hide it.

But there is a growing request for functions that can be both. I think that zig has them

https://medium.com/front-end-weekly/callbacks-promises-and-a...

Careful, it doesn't work the same way in every single language that has these keywords.

> Why can't non-async functions use await()?

Because in Javascript at least, it only makes sense to await a promise, nothing more. A function marked as async will always return a promise. You can't await on anything that is not a promise.

I think what OP is assuming is a multi-threaded or multi-process environment, where the calling function can just block whatever execution context it's running in and wait until the async function returns.

The problem is that many environments are effectively non-multi-threaded, especially the (usually single) thread/queue/process that draws the UI and responds to user input. So if you block the UI thread, your whole app (at least from the standpoint of the user) stops responding.

Still, this should work in principle, but threads are more costly in terms of memory and context switching time than continuations, so it makes sense to allow the thread to continue to handle other tasks while waiting for e.g. I/O to complete.

This is what the author of the classic https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... settles on as the best way of handling async tasks, but I recall there being some pushback on that here on HN.

In C#, you can't use the "await" keyword, but you can use the result of a Task<T> in a non-async function with ".Result" or ".GetAwaiter().GetResult()". https://stackoverflow.com/a/47648318/5107208

Well, I would say that it's the opposite of preemption. It's cooperative multitasking. Your async task is split into two tasks, with the await in the middle. When you call await, the first task finishes. The second task starts running once the await is done.

> Why can't non-async functions use await()?

In C#, they can. You can call `.RunSynchronously()` on a `Task`. C# supports lots of different TaskSchedulers that handle this differently.

C# is almost pathologically flexible here. Other languages typically assume that there is only one async task scheduler, and it's handled by the runtime. This task scheduler may be less flexible, and there are various design tradeoffs.

When I mark a function as `async`, I'm specifying that this function will be performing some form of asynchronous I/O. Any caller of that function (or its callers' callers) will therefore also be doing I/O. Such functions may take a while to "return" and are more likely to throw an exception.

Function coloring makes these properties explicit. By forcing all callers to also be `async`, it becomes easy to see which parts of the codebase are doing (somewhat risky) I/O work and which parts will be near-instant. No one ends up surprised when a call to `getFoo()` ends up getting `foo` from the network rather than the local object.

To await means to wait for a Promise to resolve asynchronously. That's why async functions return a Promise instance.

  async function asyncFn() {
    const result = await fetch(url)
    const json = await result.json()
    return json
  }
  
  asyncFn().then(json => console.log('Got', json))
  console.log('Fetching result..')

In contrast, a non-async function is synchronous, which means it's expected to run all instructions one after the other, then return a value. No other code can run while that's happening.

If await was allowed in a non-async function, it would have to block execution of all other code until the Promise is resolved/rejected.

  function syncFn() {
    const result = await fetch(url)  // Stop the world
    const json = await result.json() // Stop the world
    return json
  }
  
  console.log('Fetching result..')
  console.log('Got', syncFn())

To avoid stopping the world, a non-async function can use Promise callbacks instead.

  function promiseFn() {
    return fetch(url)
      .then(result => result.json())
  }
  
  promiseFn().then(json => console.log('Got', json))
  console.log('Fetching result..')

In JavaScript, you only have one thread. You really don't want to block it for any length of time. IO tends to take time. So IO is always async. There's no way to turn something async into something synchronous without blocking your thread waiting.

Other languages do let you block a thread to wait for an async task to complete, JavaScript doesn't mostly because there is only one thread.

  async function myFunction() {
    a();
    await b();
    let d = c();
    return d;
  }

  function myFunction() {
    return new Promise((resolve, reject) => {
      a();
      b().then(() => {
        try {
          let d = c();
          resolve(d);
        }
        catch (err) {
          reject(err);
        }
      }).catch(reject);
    });
  }

Note that you can call an async function from a non-async function. Assuming b() is async and a() and c() are not, a manual approach looks like this:

  function myFunction(callback)
    a();
    b().then(() => {
      try {
        let d = c();
        return callback(null, d);
      }
      catch (err) {
        return callback(err);
      }
    }).catch(callback);
  }

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Can it be done? sure:

   let bar = await foo();
   return bar + 1;

   let resultPromise = foo();
   while (!resultPromise.isComplete()){
       sleep(10);
   }
   let bar = resultPromise.value();
   return bar + 1;

One of the reasons this is so inefficient is that you have to spend time checking (which is wasteful if it isnt ready) and waiting. If you check more frequently, you're wasting CPU. If you spend more time waiting, you can waste up to that much time if the result is ready right after you go to sleep.

The alternative is to have the operating system tell you when its ready. This is done through the event loop. So this would turn the code transformation into something like the following:

  let resultPromise = foo().then(function(bar){
     return bar + 1;
  });
  

When you write (Python):

    await sock.write("fooooooo")

    def write(self, data):
        while data:
            try:
                written = self._socket.write(data)
            except EWOULDBLOCK, EAGAIN:
                yield 'writable', self._socket
            data = data[written:]

Because this inversion of control doesn't happen unless you (usually) explicitly wrap a coroutine (e.g. asyncio.run_until_complete) with an event loop, you can't just call a coroutine. It doesn't know when to resume in these designs, and your synchronous function doesn't know how to, either.