Can I simply say that Coroutine use the similar mounting/unmounting tech only in the main thread, but not in any other threads which creating by Dispatchers? That's why at the end of the talk we need to use virtualTheadDispatcher.
Interesting observation about threads vs coroutines. I would go one step further in that analysis: a thread is used to implement a s"service", a coroutine is used to implement a "task". They both have concurrency requirements; satisfied by respective mid-level abstractions. Under the hood, its all about continuations.
Nope:) you can start with Kotlin. If you have some Java experience you’ll notice Kotlin is less verbose, doesn’t need ;, has type inference, extremely powerful standard lib.
Great talk, but one thing I feel like was missing - Loom VirtualThreads are preemptive whereas Kotlin Coroutines require cooperative release, so for intensive CPU tasks that run in parallel, Loom will bring addition benefits.
That is common misunderstanding. Virtual threads are also cooperative that is why they are pinned in synchronized blocks and that is why JDK code calls yield to unmount virtual threads.
Both of them are used for the cases when CPU execution can be "outsourced" but what is more interesting because normal method calls suffer from augmented functionality of virtual threads and you perform CPU intensive tasks in such methods. Especially small ones. Then coroutines will give you more benefits.
@@AndreyLomakin In general synchronized block don't suffer from pinning, only when a long blocking operation is performed inside synchronized block. ForkJoinPool, which is the default scheduler, will manage it using managed blocker will compensate the threads automatically. Coroutine also has this issue if you use blocking APIs somewhere in the call chain. What i heard is they are working on removing the synchronized block pinning issue.
@@noraltavir it is i can see. I like that java is getting it but then again I have no experience with kotlins way of doing it, but I am not really feel like i am missing out on anything major. Loom has the advantage that it can deeply integrate with the jvm whereas kotlin has too do compiler tricks, since it merely uses the jvm as a runtime platform. I dont really like the compiler magic going on in coroutines but I like the plurality of approaches that the jvm affords
@@Mig440 the compiler tricks part has an advantage though. It allows kotlin to operate outside jvm. Kotlin solves another set of problems that java as a language is not currently optimized for and that is being able to run multiplatform natively. I wouldn't want to have a jvm runtime for example in my kotlin multiplatform ios project that uses coroutines extensively being dicussed in this presentation. In the end it is simply is that kotlin as a language and it's compiler and the rest of its dev environment has other goals to accomplish compared to the different goals that Java has to fill as well. No right or wrong way just different priorities which open up different opportunities, pros and cons.
@@bangonkali i know that kotlins main focus and goal is android and not server side, where java thrives. But kotlin is also used in spring, quarkus gradle and micronaut which austensibly do not care about androids ecosystem, hence my reservations about kotlin.
I know right :) Just to not dismiss his point of Coroutines providing more fine-grained concurrency. I wanted to understand the following: 1. Ignoring Google scale web services, what are the practical application of such fine-grained concurrency patterns? 2. If I have a big method and I want multiple suspension points within the method. I can just decompose the method into smaller ones and wrap them to run in a separete virtual thread. What's wrong with this approach? The comparision is too artificial IMHO
@@GK-rl5du For me the problem is how to manage errors and cancellations across virtual threads ? How to collect individual task results ? As I see it, with java threads (even virtual ones), you have to do that manually, i.e. write code to manage state across your tasks (one thread fails ? You have to stop others manually, because they don't care, they're still running. Want to combine each thread result ? You must manually join futures yourself). Coroutines and colored functions do that for you. They provide a lot of syntactic sugar to reduce the need for boiler-plate. And that is only mostly because of function coloring. In Scala ZIO and in various reactive stream libs, instead of function coloring, they use monads to represent concurrency state/cooperation. It's heavy to use, but still, far better than java.util.concurrent API. And Virtual threads don't change anything at that. So, personnally, I think that function coloring is still a win in that particular case. As I see it, it is a ligthweight method to explicitely define boundaries between a synchronous/blocking environment and an async/non-blocking one.
Learning Coroutines can take quite a long time to understand and use correctly, whereas with Project Loom everything is straight-forward and easy. That guy is not convincing at all - all I see is Coroutines have some syntax sugar on top of async abstractions, which in most cases are not that useful anymore. To prove his point he should have showed real examples of when Coroutines beat Project Loom, not just general words.
Sounds like you just don't really understand coroutines, which is fine. He mentions in this talk that this isn't a deep dive into coroutines. You should watch those if you are interested. His main point, which is that they solve different problems, is correct.
Well, you see how deep he had to go. He had to spend 45 minutes and go into highly technical stuff to argue that there's a difference. Still though, the use case for coroutines 99% of the time is that most server side code today is just threads doing some dumb processing and waiting for IO. For historical reasons, the Java VM used OS threads for this, which is terrible. All modern languages implemented their own concept of concurrence to deal with this. Kotlin coroutines are a clever way that jetbrains found to maintain compatibility with the JVM and much more readable than reactor code. Kudos to them for doing that, but now that Java is finally doing what everyone did before them, coroutines will probably die, as the use cases he mentions are not very common at all.
Kotlin devs won't use Loom over coroutines. Loom makes coroutines even better. Multiplatform can't use them, Kotlin libraries and apis which use coroutines won't switch. Looms api is clunky; it doesn't expose low level apis such as Continuation so you can't write your own resuming conditions. Kotlin has hot/cold Channels, Flows, Contexts, Sequences, error propagation etc... loom has no equivalent for any of this. As said in the video, while conceptually the same they have totally different use cases.
@@GregHib Coroutine fans always argue that Coroutine is multiplatform. That's good, but let's be realistic, Java backend devs don't care about multiplatform but only focus on JVM side. So multiplatform from Coroutine is not a benefit in backend development. Now, just because Project Loom is a project directly from Java means that Loom can deeply modify the JVM system to achieve better optimization. Just because of this fact, Loom has a much greater potential than Kotlin Coroutine that can only scratch the surface of JVM. So maybe in the far future when Loom gets more improvement (getting more APIs, more optimization from modifying the JVM, etc), people will choose Coroutine for any other platforms but not on JVM anymore
I think Kotlin will always be associated with Russia. The name comes from a russian island and the team that developed it is mostly russian. As long as this nonsensical war, like all wars, rages on, people will always find ways to associate Kotlin with the war regardless of the fact that the Intellij team pulled the Kotlin team out of Russia.
The ideal balance between high-level explanation and details. Thank you!
If the speaker is Roman then the conversation is about multithreading! 🤘🤘🤘
A very structured explanation. Thank you Roman!
45 minutes and 21 seconds of blocking IO.
:-D
As always great job!
Why do conference videos always play the intro jingle at 500% volume then the talk at normal volume?
thanks for great explanation!
Good explanation!
This is an excellent explanation! Looking forward to have a Loom and coroutines integration!
Can I simply say that Coroutine use the similar mounting/unmounting tech only in the main thread, but not in any other threads which creating by Dispatchers? That's why at the end of the talk we need to use virtualTheadDispatcher.
thank you
Every word Roman speaks is interesting
limitations with synchronized pinning can be overcome with locks such as ReentrantLock
this is why I love kotlin.
Interesting observation about threads vs coroutines. I would go one step further in that analysis: a thread is used to implement a s"service", a coroutine is used to implement a "task". They both have concurrency requirements; satisfied by respective mid-level abstractions. Under the hood, its all about continuations.
42:55 Why for less memory consumption we should use Virtual Threads? Previously Roman told that VT are memory heavier than coroutines.
But in this case it's referring to the case when you have to call an existing blocking code.
Ref "no suspend/non-suspend" distinction. Loom has `Continuation.yield`, no?
Nice
I thought that coroutines loose the stack trace when they are resumed (like callbacks). Was I wrong?
That isn't possible otherwise you wouldn't be able to restore the coroutine state since it all stored in the stack trace.
💯
what we'll cover today [1:11]
The history [1:55]
What are Loom's Virtual Threads [3:02]
Threads [3:04]
Virtual Threads [4:29]
Project Loom: Goals [5:00]
~~Existing~~ Legacy code [5:50]
Existing server-side code: example [6:44]
Handling many connections? expensive [8:55]
Existing server-side code: Loom retrofit [9:41]
Handling many connections? cheap [14:16]
Project Loom: Recap [14:53]
Project Loom: Limitations [15:24]
cannot unmount code:
- running inside native methods
- running inside synchronized sections
Let's compare Coroutines and Project Loom [17:13]
Kotlin Coroutines: Goals [17:22]
Project Loom VS Kotlin Coroutines [18:30]
focus on | Existing thread APIs | Existing async APIs
Best for | Server-side RPC code | Highly concurrent code
| Virtual thread per request | Fine-grained concurrency
Programing style differences [20:52]
Project Loom Style [20:59]
Kotlin Coroutines Style [21:56]
event handling
Structured Concurrency [23:57]
Virtual threads are still threads | Coroutines are concurrency-centric [25:45]
Implementation differences [27:51]
Implemented inside the VM | Implemented in the Kotlin compiler
Performance differences [31:11]
Performance: Memory [31:17]
Virtual Threads [31:26]
Coroutines [32:31]
Why virtual threads are heavier? [33:05]
Performance: CPU [34:30]
Performance: IO [35:41]
Tooling differences [37:32]
Project Loom + Kotlin Coroutines [39:40]
weakness of Kotlin Coroutines that Project Loom can help with?
Recap [44:22]
Gold!
I honestly don’t quite get what he mean fine grain concurrency. And how coroutine solve that issue.
I wanted to learn kotlin, do I need to learn Java?
Nope:) you can start with Kotlin. If you have some Java experience you’ll notice Kotlin is less verbose, doesn’t need ;, has type inference, extremely powerful standard lib.
Great talk, but one thing I feel like was missing - Loom VirtualThreads are preemptive whereas Kotlin Coroutines require cooperative release, so for intensive CPU tasks that run in parallel, Loom will bring addition benefits.
That is common misunderstanding. Virtual threads are also cooperative that is why they are pinned in synchronized blocks and that is why JDK code calls yield to unmount virtual threads.
Both of them are used for the cases when CPU execution can be "outsourced" but what is more interesting because normal method calls suffer from augmented functionality of virtual threads and you perform CPU intensive tasks in such methods. Especially small ones. Then coroutines will give you more benefits.
@@AndreyLomakin Who said that performance for normal methods will be affected for virtual threads?
@@zhamed9587 You are right, my bad. I confused it with consumption of resources of handling of unmounting of virtual threads.
@@AndreyLomakin In general synchronized block don't suffer from pinning, only when a long blocking operation is performed inside synchronized block. ForkJoinPool, which is the default scheduler, will manage it using managed blocker will compensate the threads automatically. Coroutine also has this issue if you use blocking APIs somewhere in the call chain. What i heard is they are working on removing the synchronized block pinning issue.
Loom also has structured concurrency fyi ✌️
And it is in the talk actually.
@@noraltavir it is i can see. I like that java is getting it but then again I have no experience with kotlins way of doing it, but I am not really feel like i am missing out on anything major. Loom has the advantage that it can deeply integrate with the jvm whereas kotlin has too do compiler tricks, since it merely uses the jvm as a runtime platform. I dont really like the compiler magic going on in coroutines but I like the plurality of approaches that the jvm affords
@@Mig440 the compiler tricks part has an advantage though. It allows kotlin to operate outside jvm. Kotlin solves another set of problems that java as a language is not currently optimized for and that is being able to run multiplatform natively.
I wouldn't want to have a jvm runtime for example in my kotlin multiplatform ios project that uses coroutines extensively being dicussed in this presentation.
In the end it is simply is that kotlin as a language and it's compiler and the rest of its dev environment has other goals to accomplish compared to the different goals that Java has to fill as well. No right or wrong way just different priorities which open up different opportunities, pros and cons.
@@bangonkali i know that kotlins main focus and goal is android and not server side, where java thrives. But kotlin is also used in spring, quarkus gradle and micronaut which austensibly do not care about androids ecosystem, hence my reservations about kotlin.
@@Mig440 to each their own 🫡
33:43 Did he just try selling function coloring as a good thing?
I know right :)
Just to not dismiss his point of Coroutines providing more fine-grained concurrency. I wanted to understand the following:
1. Ignoring Google scale web services, what are the practical application of such fine-grained concurrency patterns?
2. If I have a big method and I want multiple suspension points within the method. I can just decompose the method into smaller ones and wrap them to run in a separete virtual thread. What's wrong with this approach?
The comparision is too artificial IMHO
@@GK-rl5du For me the problem is how to manage errors and cancellations across virtual threads ? How to collect individual task results ? As I see it, with java threads (even virtual ones), you have to do that manually, i.e. write code to manage state across your tasks (one thread fails ? You have to stop others manually, because they don't care, they're still running. Want to combine each thread result ? You must manually join futures yourself). Coroutines and colored functions do that for you. They provide a lot of syntactic sugar to reduce the need for boiler-plate. And that is only mostly because of function coloring. In Scala ZIO and in various reactive stream libs, instead of function coloring, they use monads to represent concurrency state/cooperation. It's heavy to use, but still, far better than java.util.concurrent API. And Virtual threads don't change anything at that. So, personnally, I think that function coloring is still a win in that particular case. As I see it, it is a ligthweight method to explicitely define boundaries between a synchronous/blocking environment and an async/non-blocking one.
@@alexismanin5239 I think structured concurreny comming in the future will solve this
Learning Coroutines can take quite a long time to understand and use correctly, whereas with Project Loom everything is straight-forward and easy. That guy is not convincing at all - all I see is Coroutines have some syntax sugar on top of async abstractions, which in most cases are not that useful anymore. To prove his point he should have showed real examples of when Coroutines beat Project Loom, not just general words.
Sounds like you just don't really understand coroutines, which is fine. He mentions in this talk that this isn't a deep dive into coroutines. You should watch those if you are interested. His main point, which is that they solve different problems, is correct.
Well, you see how deep he had to go. He had to spend 45 minutes and go into highly technical stuff to argue that there's a difference.
Still though, the use case for coroutines 99% of the time is that most server side code today is just threads doing some dumb processing and waiting for IO.
For historical reasons, the Java VM used OS threads for this, which is terrible.
All modern languages implemented their own concept of concurrence to deal with this.
Kotlin coroutines are a clever way that jetbrains found to maintain compatibility with the JVM and much more readable than reactor code.
Kudos to them for doing that, but now that Java is finally doing what everyone did before them, coroutines will probably die, as the use cases he mentions are not very common at all.
Kotlin devs won't use Loom over coroutines. Loom makes coroutines even better.
Multiplatform can't use them, Kotlin libraries and apis which use coroutines won't switch. Looms api is clunky; it doesn't expose low level apis such as Continuation so you can't write your own resuming conditions. Kotlin has hot/cold Channels, Flows, Contexts, Sequences, error propagation etc... loom has no equivalent for any of this.
As said in the video, while conceptually the same they have totally different use cases.
@@GregHibI strongly believe those resuming api will be exposed eventually and .. loom will replace all JVM based async frameworks
@@GregHib Coroutine fans always argue that Coroutine is multiplatform. That's good, but let's be realistic, Java backend devs don't care about multiplatform but only focus on JVM side. So multiplatform from Coroutine is not a benefit in backend development.
Now, just because Project Loom is a project directly from Java means that Loom can deeply modify the JVM system to achieve better optimization. Just because of this fact, Loom has a much greater potential than Kotlin Coroutine that can only scratch the surface of JVM.
So maybe in the far future when Loom gets more improvement (getting more APIs, more optimization from modifying the JVM, etc), people will choose Coroutine for any other platforms but not on JVM anymore
bla-bla-bla
No mention about ruzzian war in timeline.
Jetbrains denounced the war and pulled out of Russia. Have any American companies done the same for Iraq/Afghanistan?
I think Kotlin will always be associated with Russia. The name comes from a russian island and the team that developed it is mostly russian. As long as this nonsensical war, like all wars, rages on, people will always find ways to associate Kotlin with the war regardless of the fact that the Intellij team pulled the Kotlin team out of Russia.
you washed your brain too much, stop it