https://kotlinlang.org logo
#random
Title
r

rtsketo

04/06/2022, 5:11 PM
Somebody got jealous of coroutines 😅
f

Fleshgrinder

04/06/2022, 5:15 PM
This can be a game changer for Kotlin Coroutines as well, really great development.
5
k

kenkyee

04/06/2022, 5:43 PM
FYI, coroutines was faster...not sure if they fixed Loom so it's faster now... https://www.reddit.com/r/Kotlin/comments/mt3h11/a_simple_benchmark_comparing_java_loom_virtual/
f

Fleshgrinder

04/06/2022, 5:57 PM
Give it time, it's for sure not easy to abstract over all supported operating systems and architectures and get it work the same way everywhere. It's also important to understand that the benchmark as presented on Reddit (and heavily improved in the best rated comment) is not a particular well fit for fibers, because the algorithm would benefit most from true parallelism instead of concurrency. (It's still a valid thing to compare, of course.) Java threads had many years to get where they are, and Kotlin just builds on top of them. If we write a benchmark that compares Java threads vs. Kotlin coroutines then I'm pretty certain that the Java code always wins. 😉
k

kenkyee

04/06/2022, 6:00 PM
Java threads vs. coroutines would overload after N thousand threads chew up all your memory 🙂
f

Fleshgrinder

04/06/2022, 6:05 PM
Well, obviously with parallelism that matches the CPU cores (or at least virtual threads). 😉
s

Stylianos Gakis

04/06/2022, 7:01 PM
I was reading this today as well, and I am curious about how this affects Kotlin coroutines? Will it be able to benefit from this being implemented? How will the interoperability story will be like when calling java code which may be creating and awaiting on virtual threads? Looks interesting, I’d love to hear more from someone more knowledgable on this subject.
f

Fleshgrinder

04/06/2022, 7:03 PM
Depending on how Loom develops Kotlin Coroutines could be changed from threads to fibers in the future and thus offer seamless interop. No idea if there is any interest in that, but that's what I meant when I wrote “game changer” above. I truly hope that there is interest, because the Java interop was always the #1 selling point of Kotlin for me, and all the mpp plays little to no role.
s

suresh

04/06/2022, 7:44 PM
For kotlin interop, it seems there are plans to make interaction with non-sus function seamless - https://github.com/Kotlin/KEEP/issues/240#issuecomment-1088988920 . But the question is, if you are targeting for JVM (mainly server side), whats the advantage of using coroutines over virtual thread? Virtual thread doesn’t suffer from coloring issue and harmonious with the platform (so better stacktraces, debuggability , profiling using JFR) . Can understand the advantage for multi platform.
e

ephemient

04/06/2022, 7:51 PM
the way kotlinx.coroutines supports and enforces structured concurrency would still be useful even in after Loom, IMO
4
s

Stylianos Gakis

04/06/2022, 7:51 PM
Coroutines come with goodies like structured concurrency, Flows etc. I’d imagine you’d not get those out of the box from simply using virtual threads, so I think the reasons to use coroutines will still be there.
s

suresh

04/06/2022, 8:09 PM
Loom has those in incubating now… Structured Concurrency and Scope Locals
f

Fleshgrinder

04/06/2022, 8:10 PM
What @suresh wrote. 😉 I expect that Loom arrives at some point at the level of functionality that we know and expect from
boost::fiber
.
j

Jason5lee

04/07/2022, 5:38 AM
I hope it will resume the suspended fun.
e

ephemient

04/07/2022, 7:33 AM
if Java does implement structured concurrency through Loom, then the remaining value of kotlinx.coroutines is in usability and portability. it'll be interesting to see what kind of interoperability may be possible
s

Stylianos Gakis

04/07/2022, 7:39 AM
Looking at the syntax proposed (may be improved upon of course) the benefits will also be from what Kotlin always did better, having nicer and less boilerplate-y syntax. Especially if kotlinx.coroutines can make use of any potential performance benefits from Loom, it will still probably make more sense to use them for a better dx. Just a guess though, who knows 🤷‍♂️
f

Fleshgrinder

04/07/2022, 7:48 AM
Better usability and nullability are the clear selling points for a Kotlin abstraction over Java Loom. As always I don't see a competition here but synergy. The Kotlin community should embrace Loom.
4
s

Stylianos Gakis

04/07/2022, 7:52 AM
Oh yeah absolutely. Just like they’ve prepared the grounds for project Valhalla with value classes.