Also I see “managing coroutines”. I’m not sure wha...

# multiplatform

[Jonathan Sandusky]

Also I see “managing coroutines”. I’m not sure what that means. I know what coroutines are, but I don’t understand the meaning of managing them in multiplatform.

So my main platforms would be Java/Kotlin and JavaScript. Will this convert any coroutines to async/await in JavaScript?

[CLOVIS]

No, coroutines use a very different system than JS' async/await, that are not interchangeable. In general, other languages cannot execute suspend functions. However for languages that have lambda support it's easy to provide a small function to bridge the gap

[Jonathan Sandusky]

I see. Do you know what is meant by managing coroutines. It’s very vague. I might ask the question in the documentation.

[CLOVIS]

Where did you see that sentence?

[Jonathan Sandusky]

https://kotlinlang.org/docs/multiplatform.html

[Jonathan Sandusky]

[CLOVIS]

It doesn't really mean anything. Basically, the language concept of coroutines itself is voluntarily kept low-level so it's easy to adapt into other frameworks (for example Rx...); At the same time, JetBrains provides KotlinX.coroutines, a complete framework that ‘manages coroutines’

[Jonathan Sandusky]

I’m still a little confused. If it’s easily adaptable does it mean we can write coroutines and have it compile into java/js/whatever ios uses or is it a mistake and multiplatform can’t do it and it’s supposed to do something I’m not understanding.

[CLOVIS]

At the bottom of everything, coroutines are essentially a compiler automation to rewrite nice looking code to callbacks, with exactly the same benefits as callback-based APIs (asynchronous stuff, easy concurrency, very lightweight especially compared to threads, etc) except that, unlike callbacks, the code is nice to look at.

Of course, coroutines work on all platforms* (the native memory model is a bit strict at the moment so many things are a bit different when there's concurrency, but they're working on it). It's completely fine to use coroutines on the JVM, or JS, etc—the problem is that, because the whole language feature is essentially really clever callback rewrites by the compiler, it has absolutely nothing in common with how specific platforms handle concurrency and asynchronous programming by themselves.

In practice, it mostly takes the part of a Continuation hidden parameter that is added to every suspend function, and is pretty much impossible to create from other languages.

Basically, Kotlin can use coroutines in every platform that Kotlin compiles to, but that platform cannot call suspend functions. Most of the time when writing Kotlin, that's not an issue because you're writing code used by other Kotlin code, but if it is an issue for you, then you'll have to provide your own wrapper over your API that translates suspend functions to that language (for example using Promise in JS). It's a shame that interop only works one way, but coroutines are just better in every way so everyone accepted it.

[CLOVIS]

Comparing those to threads; it's very rare in a real project to use threads directly. It's very common to use an additional library (Rx, ...) to handle thread pools, etc.

Coroutines are the same. In the base language, you get the suspend keyword, that does all the compiler magic, but it is fairly bare. In a real project you'll want a library that handles all the complicated stuff (creating threads, dispatching coroutines over them, switching between threads, etc). JetBrains provides KotlinX.Coroutines, which does exactly that, but you could still use suspend functions without using KotlinX (for example, Arrow uses them for their bind notation, the Sequence builder uses them to implement yield, etc).

[CLOVIS]

(in practice however, to my knowledge everyone uses KotlinX.Coroutines)