1 year ago
No, coroutines use a very different system than JS' async/await, that are not interchangeable. In general, other languages cannot execute
functions. However for languages that have lambda support it's easy to provide a small function to bridge the gap
1 year ago
I see. Do you know what is meant by managing coroutines. It’s very vague. I might ask the question in the documentation.
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’
1 year ago
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.
1 year ago
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
hidden parameter that is added to every
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
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
in JS). It's a shame that interop only works one way, but coroutines are just better in every way so everyone accepted it.
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
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
notation, the Sequence builder uses them to implement
(in practice however, to my knowledge everyone uses KotlinX.Coroutines)