In a cooperative runtime like Rust’s Tokio or Node.js, the thread does not yield until it hits an await point.

This is just because JS is single threaded. Python has the Global Interpreter Lock, which makes it effectively single threaded too. That means you don’t have to deal with true parallelism, and critical sections, semaphores etc. It’s like Ethereum: only one thing happens at a time.

But you don’t have to parse JSON without yielding. You can make anything async by just using setTimeout once in a while. Here is one such implementation: https://www.npmjs.com/package/yieldable-json

The guy may as well have said while(1) locks up Node.

Now they get into multithreaded work-stealing, and isolates. But the solution in Node is to spin up multiple processes and pass messages between them. This is approaching the Erlang actor model, and is also shared-nothing. They even say "the schedule is a single-threaded loop per core" and "all cross-core communication occurs via the messaging subsystem".

This can also be achieved in most other single-threaded languages, too. Python with asyncio, for instance.

Tina may provide a nice opinionated implementation with bounded queues and deterministic scheduling, but those are architectural choices rather than evidence that async/await itself has failed.

Node has isolates, but it's more for sandboxing.

The title of the post is "Tokio/Rayon Trap" - those are two very well known Rust libraries.

(in case you missed it, authors mention them later and explain what they do: "Use Tokio for I/O, and send CPU-bound work to a dedicated thread pool like Rayon.")

Authors have whole section ("The Work-Stealing Myth") on Erlang.

Author's proposed solution ("Project Tina") is a new programming language written in Odin.

How on earth do you read this all and start talking about Javascript problems instead?