Loom: The Kotlin Coroutines Killer?

No video

Loom: The Kotlin Coroutines Killer? | Talking Kotlin

Рет қаралды 28,985

Kotlin by JetBrains

Күн бұрын

Пікірлер: 51

@pbtungulu Жыл бұрын

5:10 actual discussion starts

@anudeepananth Жыл бұрын

Thank you

@andreypfau Жыл бұрын

Thank you for safe my time

@ssouza.himself Жыл бұрын

Thank you

@0xmg Жыл бұрын

Not all heroes wear capes

@SaadFarooq Жыл бұрын

The time wasting on these videos is incredible.

@SureshG Жыл бұрын

Most of the Kotlin Coroutines vs. virtual thread discussion focuses on just the syntax and programming model. The virtual thread has some clear advantages being implemented on JVM like, 1. Better stack traces 2. Better debugging 3. Accurate profiling using JFR/other profiling tools (It's a huge issue for reactive frameworks) 4. Better interop with all the JVM blocking libraries 5. No function coloring issues 6. Adding suspend keyword increases the byte code size (it transforms to a state machine by the kotlin compiler) 7. Faster/scalable context using ScopeLocal (it's an incubator feature) which works natively with threads. On the other hand, if you are targeting KMP, Coroutine is a really nice solution available to use in common code. Another good thing is, all of these virtual thread features we can use today in kotlin (yeah, without Coroutines).

@jondo7680 Жыл бұрын

Since Android (and wasm) won't have loom I would prefer if this would be implemented in a totally transparent way. The same coroutine code should use loom on the jvm and not use it on Android. No @notations, no virtual scopes or what ever. Copy pasting code from server code to the Android code or the other way around should simply work. I hate the invasiveness of suspend functions, but having jvm and android code the same (and on future wasm code even if all coroutines need to run in a single threaded) is the most important thing.

@mahdihosseinzadeh Жыл бұрын

Sorry. Hope not to be rude. I love you guys and this channel. But it's 5 minutes in and you are still talking non...

@raianmr2843 Жыл бұрын

you can safely skip opening 30% of most yt videos, its like a rule

@kirillalexander-rj2im Жыл бұрын

As I understand Loom in context of Java solves function colouring problem because we use direct style 'sync' functions but optimized under the hood with fibers/virtual threads. OCaml 5 language has more interesting approach with effect handlers because it allows user code level direct style IO abstractions (and more) based on any kind of IO 'engines' (libuv, io_uring, etc).

@LostMekkaSoft Жыл бұрын

it felt like the awkwardness from the beginning never truly went away :D

@jesprotech Жыл бұрын

I think the topic is interesting but at the same time, the focus of the discussion apparently has been to compare coroutines and virtual threads. Both attempts to solve the same problem with the very old concept of continuations and coroutines invented long before Kotlin had implemented Kotlin-coroutines. But there are substantial differences in how virtual threads work (JVM) and how Kotlin coroutines work (compiled code). The first comes in the JVM and it is part of its architecture whereas Kotlin coroutines are made to run in the JVM like any other code. And both can live and benefit from each other in the same JVM instance. This video is about 40 minutes long and to explain such nuances and such a potentially complicated topic, I personally would have found it better to have seen diagrams, charts, or something else like drawings.

@AlanDarkworld Жыл бұрын

The show was really good by the way. Urs knows his stuff.

@avwie132 Жыл бұрын

Coroutines is multi platform, loom isn’t. So I don’t know why it is even a discussion

@notkamui9749 Жыл бұрын

loom is not* is what you meant ?

@avwie132 Жыл бұрын

@@notkamui9749 you’re absolutely right. I had a brain fart

@pablovaldes6022 Жыл бұрын

Sounds like the JVM people designed the loom API for the Kotlin language rather than for Java. He said java code gets nasty when using it but Kotlin is ok, 🤔

@mdtanveerhasan1453 Жыл бұрын

Sad

@Asdasxel Жыл бұрын

Hmm, almost as if he was slightly biased as a Kotlin developer and advocate...

@Felix-un7yp 9 ай бұрын

I do not believe that anything will kill Kotlin coroutines, because Loom is coming years too late. Also it is very easy to interact between Coroutines and oldstyle blocking code, I wrote such wrappers with just a few lines of Kotlin.

@TheLemitek Жыл бұрын

Only if Urs could used built-in in his laptop micro, not those earbuds micro

@tsmusic9587 Жыл бұрын

i love kotlin

@stephenmorse8207 Жыл бұрын

I feel like the Loom vs Coroutines discussions should have included mention of the fact that Loom virtual threads are preemptive, whereas Coroutines require cooperative release of control, and the implications of that difference.

@AndreyLomakin Жыл бұрын

Loom virtual threads also cooperative. They preempt only in case of IO blocking calls which do cooperative call. If you wrap code in synchronized it will block code. Exactly because it is also cooperative model.

@StraplessReligion Жыл бұрын

i fall in love with coroutines so much ...

@comicalInsan Жыл бұрын

Yes, he is the all knowing person. No one knows what they are doing except for him.

@Alex-gx2sz Жыл бұрын

Weird and funny discussion. These guys hate Loom but praise Coroutines. But they don't highlight that in Coroutines you cannot block and if you have to block(you have only a blocking library for example) then Coroutines are entirely useless. My teams are moving from Java and Kotlin to Golang just only due to Goroutines. And now with Project Loom we can see a really powerful concurrency model that can battle with Go. Of course, Loom still has some limitations that Go doesn't have like pinging system thread during native code and synchronized.

@bjugdbjk Жыл бұрын

Go also deos the samething what coroutines does apart from controlling of schedulling, Could you let me know what exectly blocking thing are u referring with coroutines and which is possible with Go ?

@Alex-gx2sz Жыл бұрын

@bjugdbjk For example you cannot call any blocking library inside coroutine Let's assume you want to use plain JDBC call inside Coroutine and DB responds slowly. In this case Coroutines will not help you. It means with Coroutines you cannot use a huge amount of existing libraries, such as Hibernate, etc. But with Loom you can do it all, because Loom solved the problem with system stacks, and Coroutines just a graceful wrapper for callbacks

Жыл бұрын

Great video, thanks!

@avalagum7957 Жыл бұрын

So, if I haven't looked at reactive stuff yet, I should ignore it, shouldn't I?

@Anbu_Sampath Жыл бұрын

we avoided reactive most of the time because of huge learning curve, unless you are in must have to do in your projects.

@cod3r1337 Жыл бұрын

If you could get by without it so far, you might not need it. You should be very careful about introducing it to new or even existing projects because the benefits are probably not worth the complexity unless you really *need* extremely low latency & high scalability. I wouldn't ignore it though, you should be familiar with the concepts so that you can make an educated decision.

@jondo7680 Жыл бұрын

As far as I know coroutines in Kotlim are somewhat inspired by reactive, or at least they were aware of it existing as they designed coroutines and tried to avoid having the same problems like react. So react should be a step backwards from coroutines. I think coroutine streams are what come closest to react.

@cod3r1337 Жыл бұрын

@@jondo7680 Well, one of the use cases for Coroutines (together with Flows) is as an abstraction on top of Reactor or RxJava with the help of ready-to-use adapters. While that gives you a nicer programming model on the surface as well as some kind of standardization, such extra abstraction layers don't come for free. They increase overall system complexity and don't entirely free you from having to understand the thing that is being abstracted away. The benefits may or may not be worth the price depending on context.

@jondo7680 Жыл бұрын

@@cod3r1337 ah I see that only as an easier way of migration. Yes you can use coroutines with rx java. As you can use Kotlin code in your Java project. But I would definitely not expect the flagship experience from that. I wouldn't compare these scenarios. Like in the world of gui, I worked somewhat with tormadofx. But I run into some problems there. Later compose became a thing, made directly for Kotlin and I used it in another project. It worked so well. I worked with coroutines also, and yes I didn't need to know anything about rx java because I didn't use it at all. I used my knowledge about java threads, but on Stack overflow I could see that even knowledge about java threads can misslead some people who are trying coroutines, so it might be best to use them with a clean mind without knowledge about any of the other concurrency models.

@royalanimations007 Жыл бұрын

I am waiting

@AndrasHatvani Жыл бұрын

TL;DW?

@muhammadibrahim1930 Жыл бұрын

Saif Ali Khan teaching Kotlin

@AlanDarkworld Жыл бұрын

Will loom end Coroutines? Hopefully yes. And all the reactive discussion with it. It's hard to write, hard to read, hard to debug. Saves the effort of code obfuscation though.

@mr_gryphon Жыл бұрын

Coroutines aren’t really associated with “reactive”; they allow structured concurrency that looks like standard blocking code

@vasiliychernov2123 Жыл бұрын

Flows ≠ Coroutines. Flows are *based on* Coroutines, but Coroutines themselves don't have anything to do with reactive programming.

@codeforandroid Жыл бұрын

@faakhy2954 Жыл бұрын

🎉

@MeManeenotOpal Жыл бұрын

จ่ายเงินค่าเบียร์มาค่ะ

@krellin Жыл бұрын

oracle copying jetbrains homework oracle copying googles homework interesting times... maybe oracle dedicate some resources to advance the language for develoeprs? instead of waiting for someone else to take you out of business

@raianmr2843 Жыл бұрын

You mean advancing Java? I really doubt if that's even possible. Tech debt comes in all shapes and forms and Java has an insane amount of exactly that. Just look at java.util.Optional, Java's 'solution' to the null, instances of which can themselves be null making it completely useless and even misleading for most intents and purposes. This is a permanent addition to the language. They will *never* solve null, and no amount of money or developer time can fix that. Obsolesce is a very natural property of technology, it's only when corporate interests come into play that these technologies refuse to die and become zombies devouring everything in sight.

@krellin Жыл бұрын

@@raianmr2843 most of things that kotlin did are completely backwards compatible with java 1.0 so i do not think your point is valid... kotlin itself it nearly 99.9% backwards compatible (for example package protected is gone so broken...) but everything else is... they could make coroutines, extension functions, val/vars all of that was doable on java but oracle had 0 incentive to do it after using java forever and never switching to any other language (yeah i'm that stubborn) kotlin was the only language i actually decidedly switched to.