Jonathan Sandusky

    Jonathan Sandusky

    1 year ago
    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?
    c

    CLOVIS

    1 year ago
    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

    Jonathan Sandusky

    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.
    c

    CLOVIS

    1 year ago
    Where did you see that sentence?
    Jonathan Sandusky

    Jonathan Sandusky

    1 year ago
    c

    CLOVIS

    1 year ago
    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

    Jonathan Sandusky

    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.
    c

    CLOVIS

    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
    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.
    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).
    (in practice however, to my knowledge everyone uses KotlinX.Coroutines)