> Basically any time any virtual thread does something expensive/blocking, all the other virtual threads suffer. Most Java APIs like socket and file have been

> Basically any time any virtual thread does something expensive/blocking, all the other virtual threads suffer. Most Java APIs like socket and file have been re-written to do this for you under the hood. You're not expected to manually call suspend. > Just not the other way around without creating a co-routine context. This goes beyond function calling though. Same restrictions apply for implementing interfaces or passing functions as arguments, right? With loom, there is just one world. A function is a function is a function. It's good that both Java and Kotlin can take advantage of this improved model. > Under the hood it likely does many of the same things that Kotlin already did. Maybe, but this also extends to debugging, heap dumps and stack traces. Having this builtin has a lot of benefits.