Looking at Project Loom (introducing Fibers that l...

# coroutines

[CLOVIS]

Looking at Project Loom (introducing Fibers that look a lot like coroutines to Java), will it change anything in how coroutines work? Will they be reimplemented on top of fibers? Apparently fibers will be able to suspend on blocking IO calls (which coroutines can't, AFAIK)... Will this be taken advantage of in Kotlin?

[Czar]

So far Kotlin was very slow to take advantage of newer JVM features, there are still no optimisations for current versions of JVM above 8. There was a nice talk at KotlinConf comparing current Kotlin with Future Java, what I found particularly interesting was that the speaker talked to some extent about possible optimizations in Kotlin based on new JVM features.

[Czar]

I guess JB wants to fix biggest frustrations first, there are a lot of important rewrites in compiler and tooling going on currently and scheduled to start landing with Kotlin 1.4
Maybe when that's complete optimizations for new JVMs will get prioritized a bit higher than they're now (not prioritized at all).

[fred.deschenes]

Kotlin being able to compile to multiple JDK bytecode versions is probably also a big part of why those optimizations are more complex to implement/maintain than if you know you're just compiling to 1 specific version

[Czar]

Yep, even if you skip the non-LTS releases, it's a lot of branching already. So, I say let's be patient, these performance improvement don't make or break the process for most, development performance - does. I can't wait for IntelliJ to stop hanging for several seconds to tens of seconds on syntax highlighting, refactoring and error analysis.

[kenkyee]

Another thing is GraalVM currently only supports JDK8 byte code. If Kotlin supports higher JDK versions, there's a chance I'll no longer be compatible.

[gildor]

Most probably Loom will not be is relevant for Kotlin Coroutines, Kotlin Coroutines is compile time feature (which is also works on all Kotlin platforms), you don't need any runtime support from loom and no real reason to reimplement it

But some integration of course possible in future

Loom converter for blocking calls may work in Kotlin without additional changes, otherwise it would make them useless for all existing JVM libraroes, so I don't think that any integration is needed

Anyway, it's too early for now to be sure, loom is not even close to finalization