Ah no, I mean virtual threads as specific to core.async, which predates that work by many years (they mention virtual threads in the core.async docs so I stuck with it). The virtual threads implementation (maybe they are called fibers IIRC) under project Loom are quite a bit more general than what core.async provides inside of go blocks.
There are limitations to what go allows, although I find they can typically be worked around without much issue.
In contrast, I believe that Loom virtual threads are operating at the JVM level, and don’t face these constraints (the constraints are introduced by the compiler used to implement go).