Maybe through some kind of non-preemptive user-space scheduling you mean?
Why? If you know your thread won't be interleaved with any other until you a well-defined point, how's that different to using a mutex or semaphore?
Of course all projects will benefit from Loom. I am merely positing that Clojure in particular could leverage this both most quickly and to very deep positive effect, due to the nature of the language itself putting immutability first, which if I recall correctly they built up a pattern of concurrent execution around already.
Kotlin too will be be able to optimize their concurrency story.
I simply wanted to posit an observation I hadn't seen elsewhere on the web about Project Loom yet.
Edit to add: I hadn’t initially thought to speculate on the language itself taking advantage, but it occurred to me immediately after posting this comment. Another potential benefit is that many of its fundamental abstractions (most collection APIs are declarative) lend really well to making those operations concurrent, which is a common FP/lisp hypothetical but becomes more tangible if coroutines are less expensive. This isn’t dissimilar to how RDBMS query planners can provide wild performance improvements without any semantic changes, because SQL queries express “what” now “how”.