Hacker News Reader

Comment by lbalazscs | Hacker News Reader

Ideally knowing "what is synchronous and what is asynchronous" shouldn't be your concern, just like freeing memory isn't your concern in a language with garbage collection. Similarly, you don't have to know the "real" memory addresses when using virtual memory.

Ask yourself why do you want to know what is asynchronous. In a typical server-side app synchronous, blocking, thread-per-task code is easy to write and read. There is only one drawback: you can run out of kernel threads. Asynchronous code solves this problem, but virtual threads solve it in a better way, because you can have three orders of magnitude more virtual threads compared to kernel threads. Ultimately, it's all about the number of threads you are allowed to use.

View on HN

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.

Reply on news.ycombinator.com