is anyone aware of any plans for the concepts of p...

# kotlin-native

[Wietlol]

is anyone aware of any plans for the concepts of project loom (mainly virtual threads with fibers) to be implemented in kotlin native?
i am aware that it is not a simple copy paste operation and would be a big project to re-implement it, but the effective benefit of virtual threads is massive, so imo, it is certainly worth implementing

[Big Chungus]

What would be the benefit of it when we already have coroutines?

[John O'Reilly]

Some discussion about that in https://twitter.com/kotlin/status/1427676664516030473?s=20

[Wietlol]

the primary benefit would be that it is not bound to context.
coroutines only work in the context of a coroutine scope, which cannot be passed around so easily and when passed around, requires those targets to also be coroutine scopes
in essence, it breaks the execute-around pattern, which, especially in kotlin, is very often used (and for good reason)
usually, to fix incompatibility, we simply duplicate a portion of our code and effort to work with and without coroutine scopes

[napperley]

Project Loom is JVM specific, and wouldn't apply to Kotlin Native. Some platforms like Linux have Multithreading available as an option which works differently from the JVM. Do note that the Kotlin Native runtime doesn't have Multithreading support yet 🕐 so it can't be used with Coroutines for interop purposes (eg with C libraries) 😦.

[Tijl]

Loom does this by essentially replacing every blocking method in the JDK (well, that’s more or less the goal) and rewriting them using “fibers” and “continuations”. (you can guess what those work like)

Kotlin/Native on the other hand, typically uses direct platform APIs for things that block.

Nothing really stops you from having Loom like APIs (taking the current memory model into account of course), just like Kotlin/JVM doesn’t make using a Loom based API implementation impossible.

In fact it’s kind of easier, since there’s not really an API to replace to being with.