Async/Await is finally back in Zig

Is it time now to say that async was a mistake, a-la C++ exceptions? The recent futurelock discussion[1] more or less solidified for me that this is all just a mess. Not just that one bug, but the coloring issue mentioned in the blog post (basically async "infects" project code requiring that you end up porting or duplicating almost everything -- this is especially true in Python). The general cognitive load of debugging inside out code is likewise really high, even if the top-level expression of the loop generator or whatever is clean.

And it's all for, what? A little memory for thread stacks (most of which ends up being a wash because of all the async contexts being tossed around anyway -- those are still stacks and still big!)? Some top-end performance for people chasing C10k numbers in a world that has scaled into datacenters for a decade anyway?

Not worth it. IMHO it's time to put this to bed.

[1] No one in that thread or post has a good summary, but it's "Rust futures consume wakeup events from fair locks that only emit one event, so can deadlock if they aren't currently being selected and will end up waiting for some other event before doing so."

I really wish people would get over the coloring meme.

Knowing if a function will yield the thread is actually extremely relevant knowledge you want available.

Look at the node.js APIs: readFile, readFileSync, writeFile, writeFileSync ... and on and on. If that's not a meme then I don't know what is.

And the alternative without async-await is ? blocking the event loop or the callback pyramid.

Node is one place where async-await has zero counter arguments and every alternative is strictly worse.

They could have added threads to Node as well? Granted, it would have been a lot of difficult work.

Losing threads and moving to the async I/O model was the motivation behind Node in the first place.

https://nodejs.org/en/about

If you use async I/O you can just use the Chrome JavaScript runtime as-is. I would claim it was the only low-effort model available to them and therefore not motivation.

The motivation for node was that users wanted to use JavaScript on the server.

> If you use async I/O you can just use the Chrome JavaScript runtime as-is.

What do you mean? A JS runtime can't do anything useful on its own, it can't read files, it can't load dependencies because it doesn't know anything about "node_modules", it can't open sockets or talk to the world in any other way - that's what Node.js provides.

> I would claim it was the only low-effort model available to them and therefore not motivation.

It was a headline feature when it released.

https://web.archive.org/web/20100901081015/https://nodejs.or...

Obviously you can add modules calling to C/C++ functionality to a scripting language runtime easily (and the interface to do that is already available for the browser implementation).

In the above link Node could be described as a Chrome V8 distribution with modules enabling building a web server.

Adding threading to a non-threaded scripting runtime is another ball game.

The point is that Node was forced into this model by V8 limitations, then sold it as an advantage, however, it is only one way to solve the problem with its own trade-offs and you have to look at the specific use case you are looking at to see if it is really the best solution for your use case.

> Obviously you can add modules calling to C/C++ functionality to a scripting language runtime easily

Yes, obviously, that's what NodeJS does. But you can't "just use the V8 runtime as-is if you're doing async IO", it doesn't have those facilities at all.

Async IO wasn't just "sold as an advantage", it is an advantage. Websockets were gaining popularity around that time and async IO is a natural fit for that.

You would have to change the language and boil the ocean to make the runtime support multiple threads (properly).

But why? Just to end up with the inferior thread-per-request runtime (which by the way, still needs to support async because it's part of the language), that requires developers to write JS which is incompatible with browser JS, which would've eliminated most of the synergy between the two?

I really don't understand what you're going for here. I don't see a single advantage here.

I think green threads (Java Virtual Threads, Go to an extent) are strictly superior to async/await.

If you don't have many threads, OS threads are okay as well. It is all about memory and scheduling overhead.

But that is just my opinion. You are welcome to have a different opinion.