Async vs green threads doesn't alter the number of running threads available to you, it's simply a difference in how the runtime schedules your virtual threads on the limited number of real threads. Async/await is cooperatively scheduled, Java's virtual threads are preemptively scheduled.

Both can have similar performance characteristics, the difference is primarily one of ergonomics, and since that's subjective there are people who will argue fiercely for either side.

I’m not really sure that it is all that subjective — plain old serial, blocking code is objectively easier to reason about than “jumping around” code.

It’s a different question that async-await may have a few very specialist use-cases, that is not readily available in the preemptive model.

> blocking code is objectively easier to reason about than “jumping around” code.

This is precisely why await was introduced in the first place. Promise and callback code was impossible to reason about.

A Promise is not ordinary blocking code.

String res = someRestCall();

is.

I was agreeing with you. They introduced await because they know that

    var s = await someCall();

is way easier to reason about than:

    someCall().then(…)

Oh, I see! Sorry for the misunderstanding!

Major nitpick: also virtual threads are cooperatively scheduled on carrier threads (the underlying platform threads). You "cooperate" implicitly by calling APIs that block the thread. There is no preemption if you hog the carrier thread with, say, number crunching or array sorting.

Straight from JEP 444:

> The scheduler does not currently implement time sharing for virtual threads. Time sharing is the forceful preemption of a thread that has consumed an allotted quantity of CPU time. While time sharing can be effective at reducing the latency of some tasks when there are a relatively small number of platform threads and CPU utilization is at 100%, it is not clear that time sharing would be as effective with a million virtual threads.