7 ms·

I wonder how this gonna compare with Kotlin Coroutines[0] 0: https://kotlinlang.org/docs/coroutines-overview.html https://kotlinlang.org/docs/coroutines-overvi

by yla92 5y ago

I wonder how this gonna compare with Kotlin Coroutines[0] 0: https://kotlinlang.org/docs/coroutines-overview.html https://kotlinlang.org/docs/coroutines-overview.html

lmm 5y ago
It's like an implicit, magic version of them. If the implementation is perfect then it will work great and make Kotlin coroutines obsolete. If the implementation isn't perfect, everything will work great until it hits whatever corner case and blocks everything (just like when you block on a coroutine without properly shifting to a blocking executor, only less visible and harder to diagnose).
- haimez 5y ago
  Arguably more visible because you have native JFR support for noticing such an event. Let’s remember, that Kotlin is a guest language and that the host platform implementations get host platform integrations natively.
  - lmm 5y ago
    In my experience plain old userspace code is always the easiest thing to debug, so a guest language (where a large chunk of the runtime itself will be, by definition, just plain old code) often ends up easier to understand.
    - haimez 5y ago
      In general, I would agree with you- because Kotlin or Java that corresponds to your own code should be easier to find and understand than hotspot’s C++ source code or the jit output. Last I checked though, Kotlin was threading coroutine suspend/resume points into methods as part of bytecode generation (it’s been a while, please do let me know if I’m wrong on this) which is not something most engineers are ready to read in the simple case, much less when trying to interpret the compiler’s name mangling scheme. In either case, the implementation that ships with the JVM will be more capable because of it’s privileged position of integrating with the runtime, so good news! Eventually Kotlin might be able to use the native facility.
  - pjmlp 5y ago
    Not only that, Kotlin has decided to marry Android as the platform language, so all JVM features not adopted by Google into ART means that Kotlin needs to decide to which master to obey, and with time Kotlin only path are to become its own platform. Hence why JetBrains is so eager with creating duplicates from every Java library in Kotlin.
    - tadfisher 5y ago
      JB is investing heavily into native, JS and wasm compiler backends, so there's a counterpoint. Another is that Kotlin is steadily adding support for features in newer Java runtimes, such as records. Another is that the Kotlin/JVM backend can target up to Java 17 bytecode, which is obviously not supported by Android. This reads heavily of FUD.
      - pjmlp 5y ago
        JB is trying to become Borland, with Kotlin as their Delphi while moving away from the JVM, turning Kotlin into a platform, lets see how high they fly, specially if Google's wind stops blowing.
      - kaba0 5y ago
        That just causes it to become even more fragmented. Like, is there a solution that will map well to all three/four platforms? Highly doubt.
jillesvangurp 5y ago
Jetbrains already announced that they will be making use of this in their coroutines implementation on the JVM (they have native and js implementations as well). So, in practical terms, very little will change for Kotlin users except they gain a few additional ways to configure a co routine scope with a virtual thread pool instead of a real one when using the latest JDK that will have this. I imagine they might make using virtual threads the default for the so-called Main CoroutineScope on the JVM. Right now that would be a single native thread. So, every time you call launch or async, it might be backed by a virtual thread. Virtual Threads are a somewhat lower level primitive than what co-routines provide. It will allow other frameworks on the JVM to integrate and benefit from it in a similar way. E.g. Vert.x, RX Java, Spring's Flux, etc. Probably using this directly is not a great idea as there are so many nice frameworks to choose from already that will protect you from doing silly things. But it is nice to have a good implementation of this built into the JVM. Kotlin's co-routines is somewhat unique in how it can work with and seamlessly integrate code written for other concurrency and asynchronous frameworks. So technically, this is just yet another thing that they can work with. If it has something that resembles a callback, a promise, a future, etc. you simply wrap it with a suspendCoRoutine and the resulting function is a nice suspending kotlin co-routine friendly function. Kotlin's co-routine library ships with extension functions for Spring Flux, RX Java, and a few more things and it is easy to write your own ones. It's a great way of taking away the pain of using those frameworks directly. In the browser, you have similar extension functions on javascript promises, and so on. I've been doing a lot of Browser UI programming using Kotlin JS lately. Co-routines are very nice for that. Works very similar to how I use them with Spring Boot to implement non blocking APIs. We actually share a lot of kotlin code between client and server.

by yla92 5y ago

I wonder how this gonna compare with Kotlin Coroutines[0] 0: https://kotlinlang.org/docs/coroutines-overview.html https://kotlinlang.org/docs/coroutines-overview.html

lmm 5y ago

It's like an implicit, magic version of them. If the implementation is perfect then it will work great and make Kotlin coroutines obsolete. If the implementation isn't perfect, everything will work great until it hits whatever corner case and blocks everything (just like when you block on a coroutine without properly shifting to a blocking executor, only less visible and harder to diagnose).

haimez 5y ago
Arguably more visible because you have native JFR support for noticing such an event. Let’s remember, that Kotlin is a guest language and that the host platform implementations get host platform integrations natively.
- lmm 5y ago
  In my experience plain old userspace code is always the easiest thing to debug, so a guest language (where a large chunk of the runtime itself will be, by definition, just plain old code) often ends up easier to understand.
  - haimez 5y ago
    In general, I would agree with you- because Kotlin or Java that corresponds to your own code should be easier to find and understand than hotspot’s C++ source code or the jit output. Last I checked though, Kotlin was threading coroutine suspend/resume points into methods as part of bytecode generation (it’s been a while, please do let me know if I’m wrong on this) which is not something most engineers are ready to read in the simple case, much less when trying to interpret the compiler’s name mangling scheme. In either case, the implementation that ships with the JVM will be more capable because of it’s privileged position of integrating with the runtime, so good news! Eventually Kotlin might be able to use the native facility.
- pjmlp 5y ago
  Not only that, Kotlin has decided to marry Android as the platform language, so all JVM features not adopted by Google into ART means that Kotlin needs to decide to which master to obey, and with time Kotlin only path are to become its own platform. Hence why JetBrains is so eager with creating duplicates from every Java library in Kotlin.
  - tadfisher 5y ago
    JB is investing heavily into native, JS and wasm compiler backends, so there's a counterpoint. Another is that Kotlin is steadily adding support for features in newer Java runtimes, such as records. Another is that the Kotlin/JVM backend can target up to Java 17 bytecode, which is obviously not supported by Android. This reads heavily of FUD.
    - pjmlp 5y ago
      JB is trying to become Borland, with Kotlin as their Delphi while moving away from the JVM, turning Kotlin into a platform, lets see how high they fly, specially if Google's wind stops blowing.
    - kaba0 5y ago
      That just causes it to become even more fragmented. Like, is there a solution that will map well to all three/four platforms? Highly doubt.

jillesvangurp 5y ago

Jetbrains already announced that they will be making use of this in their coroutines implementation on the JVM (they have native and js implementations as well). So, in practical terms, very little will change for Kotlin users except they gain a few additional ways to configure a co routine scope with a virtual thread pool instead of a real one when using the latest JDK that will have this. I imagine they might make using virtual threads the default for the so-called Main CoroutineScope on the JVM. Right now that would be a single native thread. So, every time you call launch or async, it might be backed by a virtual thread. Virtual Threads are a somewhat lower level primitive than what co-routines provide. It will allow other frameworks on the JVM to integrate and benefit from it in a similar way. E.g. Vert.x, RX Java, Spring's Flux, etc. Probably using this directly is not a great idea as there are so many nice frameworks to choose from already that will protect you from doing silly things. But it is nice to have a good implementation of this built into the JVM. Kotlin's co-routines is somewhat unique in how it can work with and seamlessly integrate code written for other concurrency and asynchronous frameworks. So technically, this is just yet another thing that they can work with. If it has something that resembles a callback, a promise, a future, etc. you simply wrap it with a suspendCoRoutine and the resulting function is a nice suspending kotlin co-routine friendly function. Kotlin's co-routine library ships with extension functions for Spring Flux, RX Java, and a few more things and it is easy to write your own ones. It's a great way of taking away the pain of using those frameworks directly. In the browser, you have similar extension functions on javascript promises, and so on. I've been doing a lot of Browser UI programming using Kotlin JS lately. Co-routines are very nice for that. Works very similar to how I use them with Spring Boot to implement non blocking APIs. We actually share a lot of kotlin code between client and server.