> async/await allows you to do multiple things in parallel. I don't see how you can do that in the virtual threading model, although I haven't used it and only

> async/await allows you to do multiple things in parallel. I don't see how you can do that in the virtual threading model, although I haven't used it and only read this article. You would have to spin up threads and wait for them to finish, which IMO is much more complicated and hard to read I think there's a fundamental point of confusion here. In both python and JS, you can't do anything in parallel, since node/v8 and cpython are single-threaded (yes if you dip down into C you can spawn threads to your heart's content). You can only do them concurrently, since only when a virtual thread blocks can you move on and schedule another thread in your runtime. In c++ (idk the java syntax, imagine these are runtime threads): std::thread t1(doThingOne, arg1); std::thread t2(doThingTwo, arg2); t1.join(); t2.join(); // boost has a join_all I'm sure there's some kind of `join_all` function in Java somewhere. Imo this is even more clear than your async await example: we have a main thread, it spawns two children, and then waits until they're done before proceeding. The traditional problem with async/await is that it forces a "are your functions red or blue" decision up-front (see classic essay https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...). > Finally it's generally much easier implement new libraries with a promise/future based async/await system than with a system based on threads How so? Having written a bunch of libraries myself, I have to say that not worrying about marking functions as async or not is a great boon to development. Just let the runtime handle it.