Kotlin Cookbook: coroutines vs project Loom

[Yury Nebieridze]

Both Kotlin's coroutines and project Loom's fibers are called as "lightweight threads", both use continuations in the same sense of computation that may be suspended and resumed.
Can you please share your insight on that, if any? Also is there anything you don't like about coroutines, any practical issues you faced?

[Kenneth A. Kousen]

People like Brian Goetz (super architect at Oracle) claim that eventually Java fibers will put coroutines out of business, but we'll see. I think it's going to be a long time before they appear in the language in a usable form.

The biggest issue I have with Kotlin coroutines is that people talk about them like they're simple. It's true that the resulting code is way simpler than using callbacks, but I like to say "just because coroutines make it easy to write concurrent code, doesn't mean coding concurrency is easy".

The "structured" concurrency Kotlin employs by using things like coroutineScope is really helpful, but no matter how you deal with it, there are a lot of moving parts to understand. That said, the more I get used to them the more I like them. I suspect they will be mostly hard for library developers, but that clients will have a much easier time.

In Android, one of the dominant libraries for accessing restful web services is called RetroFit (built on top of OkHttp). Both have recently been revised to support coroutines, and they're great.

So my only real reservation about them is complexity. The learning curve (at least for me) was not a small one. It took me a long time to write that chapter in the book. Hopefully I did a decent job of it. Also see Venkat Subramaniam's book Programming Kotlin for some good examples and explanations of them.

[Yury Nebieridze]

Thanks for the detailed reply, Ken!
Yes, I've got the same feeling that coroutines is not a concurrent programming silver bullet and should be used with a great care and very good understanding of underlying constructs.
coroutineScope along with launch and async functions and suspend keywords, require careful recipes for specific use cases.

I am looking at Kotlin from the server side/full stack developer's point of view and thus am interested in its react, multi-plutform abilities as well.
 
Thanks for the reference, I've seen some presentations of Venkat and will take a look at his book.

[Kenneth A. Kousen]

The good news is that while there are a lot of constructs, there are only a handful of use cases that come up over and over again. So working with `launch` and `async` and `coroutineScope`, etc, becomes manageable. Doesn't mean you don't have to be careful, as you said, but at least you're not always starting from scratch.

Good luck with the multi-platform approach. There are some notable successes, so there are decent examples to base your work on. I just don't feel confident enough in my understanding of the other platforms yet to spend time understanding the details.

[Yury Nebieridze]

Agreed, Kotlin indeed is concise and usable, so I share your concurrency (and not only) manageability optimism. Need more practice and experience though .

Yes, I noticed code generation issues, like for JVM of javascript, so code consistency looks like an issue in multi-platform promise. But, same here, deeper insight is required. Thanks again for an interesting discussion.