Hacker News Reader

Comment by proc0 | Hacker News Reader

What are you "awaiting" in a sync function? There's nothing to wait for, at the very least it may be you are looking for similar under-the-hood functionality of splitting functions, but even then you would name it something else. Regular functions just execute as expected, and splitting them would have no real effect on overall performance.

View on HN

I'm awaiting for the promise of the function I'm calling to resolve, similar to what I do in an async function. Why is there nothing to wait for?

Actually I don't understand why the `async` keyword is needed at all.

If you're waiting, it's not synchronous by definition. It's already an asynchronous function.

This is kind of turning the classical definitions on their head.

Synchronous I/O functions don't rerurn until the I/O is complete (or complete enough, anyway). The calling function effectively waits for completion.

Asynchronous I/O functions return right away, but completion is signaled elsewhere. The calling function does not have to wait (but it can choose to wait for completion if necessary). Asynchronous messaging may not even provide a completion signal, if you want to know it got there, the other side needs to send an asynchronous message back to confirm.

Await/async is confusing enough without redefining terms to mean their opposites.

Yes, exactly what I was thinking. I think that I was confused in the first place because `await` I thought meant "block until this function returns". Whereas it really means: "don't wait, swap me out".

Yeah, I think a lot of that is the interface isn't great/the abstraction is leaky and you need to know a lot about the details. Because implementations of async/await seem to usually rely on some sort of thread sharing, await also implies yield, and there's often no or limited preemption. Of course, in Javascript, you don't usually have multiple threads at all (unless you fit into one of the special exemptions that allow multiple threads), so your options are pretty limited.

If you want your function to block until the promise resolves, then the function calling it also has to block, and the function calling that has to block, and so forth.

At the top of the chain, this ultimately blocks the entire event loop (Javascript semantics are generally not concurrent), so no UI/network events can be processed until that promise resolves and the page/server is left non-responsive.

(And that's assuming you can somehow define clear semantics to run any Javascript code involved in resolving the promise; otherwise, you're deadlocked!)

If you have one thread, and it's just in a loop checking and rechecking on a promise to resolve, you will deadlock, because nothing is actually running the async function.

Await actually pauses your function and allows the async runtime to work on other stuff, such as completing the function you just awaited on.

At least in python it is needed so that the interpreter can issue very cryptic syntax errors.

No, I'm not bitter.

> Actually I don't understand why the `async` keyword is needed at all.

Indeed:

    $ raku -e'sub non-async { await start { say "hello world" } }; non-async'
    hello world

Reply on news.ycombinator.com