I came across this article: https://dev.to/martinhaeusler/why-i-stopped-using-coroutines-in-kotlin-kg0 . Does anyone have any thoughts about these arguments? I personally use coroutines mostly on single-threaded JS platform but I'm very interested how they perform on the server-side.

I think these arguments can be justified, but it's also made very clear by the coroutines devs that normal thread-based utilities like locks and

synchronized

should not be used with coroutines, and developers should instead opt for higher-level utilities provided in kotlinx.coroutines. On the other hand, I think the debugger issue should be looked into

This all rings like "I have my tools and they all work different now!" IE: hes got a set of (frankly very good) tools, and now hes being offered a new set of weird tools --maybe even immature tools (eg kotlin debugging) that work different. Hes not wrong... But: nothing there is new to me and he misses some things like : - debugging coroutines is weird, but not unsolvable.

-Dkotlinx.coroutines.debug=true

helps. - I've solved a similar problem to his threadlocal problem with DI and guice factories - his issue with "my syncing primatives don't work anymore!" is undoutably true, and, IMHO, warrants a language change that should forbid calls to

java.util.sync

from

CoroutineScope.() -> Unit

blocks. Most have alternatives, many are not as mature as java's. Again he doesnt mention

kx.coroutines...Mutex

- regarding scaling, theres an elegance to coroutines that is really hard for me to ignore. you get so much more out of each mb of heap (and thus each thread) with coroutines, that coroutines represent an order of magnitude more scalability than traditional "bigger-thread-pool & more-instances" solutions. I have little exposure to this myself. tl;dr his arguments are valid but just as immature as kotlinx.coroutines. His problems are solvable and indeed being worked on.

My 5 cents here. 🙂 Article:

Debugging

I'm not a big fan for massive usage of step-by-step debugger itself (so it's definitely not a "major pain" for me). But this issue is more about tooling support, not coroutines mechanism. I think JB will fix/improve it soon. Besides that coroutines have quite good debugging support (https://github.com/Kotlin/kotlinx.coroutines/blob/master/docs/debugging.md). Article:

The real problem is that coroutines do not inherit the context automatically.

It's not true. If we open documentation (https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-coroutine-scope/) we can see this:

Defines a scope for new coroutines. Every coroutine builder is an extension on CoroutineScope and inherits its coroutineContext to automatically propagate both context elements and cancellation.

I can't agree with thesis that

[CoroutineContext] has a horribly over-engineered API and is cumbersome to use

Usually we need to care only about scope (for structured concurrency) and dispatchers (when we need to change them). Article:

synchronized will no longer do what you think it does

Works totally as designed as for me. Whole coroutines documentation and many articles emphasizes that concurrency is not parallelism. And it's very important principle. Coroutines have many idiomatic ways to do this (e.g. Channels, Actors etc). More here (https://kotlinlang.org/docs/reference/coroutines/channels.html) and here (https://kotlinlang.org/docs/reference/coroutines/shared-mutable-state-and-concurrency.html). Coroutines library also has it's own implementation for

Mutex

(https://kotlinlang.org/docs/reference/coroutines/shared-mutable-state-and-concurrency.html#mutual-exclusion) and

Samaphone

(https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.sync/index.html). To summarize (with all respect) I feel like author of this article didn't get good comprehension about coroutines design, usage and problems they are solving. There is no need to use every new-shiny-thing in the project. Every tool has it's purpose and set of problems it solves. As for me, I'm heavily using coroutines on JVM (mobile, desktop, cli applications). All of them (especially mobile and desktop) using both concurrency and parallelism and coroutines feels like AWESOME tool that solves huge pile of problems without increasing cognitive load (in contrast to some other solutions). Proper using requires understanding of new tool (e.g. structured concurrency) but it's not difficult at all (it's just same imperative programming paradigm but functions can be paused in some points). If it's not a problem for mortal industrial developers, I suppose it shouldn't be a problem for PhD guys as well.

Agree with both @dector and @groostav, this reads like someone tried to merge usage of kotlinx.coroutines and java.util.sync and got upset when that didn't work. The semantics are different, and mixing the two can lead to odd results, as he found

yeah @dector

I'm heavily using coroutines on JVM (mobile, desktop, cli applications)

you and me are coming from the same place, and we've both found coroutines to be a good thing. I think its worth mentioning that Microsoft overhauled huge parts of .net just to make the common file API's use their

async

primatives by default. They did this because its so easy to write a win-form that go "not responding" when you click anything. For local apps (where "UI thread confinement" is king) a nice set of async/coroutine'd file, DB, and network APIs is a huge win for both readability and correctness. Without coroutines you very quickly end up not just in callback hell, but state-machine hell. For app-servers doing json transforms, maybe the value is deminished? I would think that if I launched myself into a ktor project, you would want to ask yourself "does this piece of logic I'm reading need to do some async IO? Can I load that resource now, from my nice

suspend fun

context, and then pass a POKO into a little simple piece of non-coroutine-based business logic? Of course, this requires a clear Data Abstraction Layer (DAL), which, in my experience, is always elusive and expensive.

@groostav Yeah,

async

-based concurrency and coroutines implementations seems quite quite good and successful trend in modern programming languages. Even big Java gonna have it's own (https://openjdk.java.net/projects/loom/). As far as I know, server-side problems are not-so-different in many cases (Careful! "I'm not an expert, but" ahead 😃) : Akka/Fibers was huge success on server-side, node.js, goroutines. Alibaba even implemented their own coroutines in JVM fork (https://www.reddit.com/r/java/comments/aqwvqq/extreme_scaling_with_alibaba_jdk/). I hope (and believe) that all this efforts are another one small step towards building better software with higher quality. And it seems that Kotlin coroutines has quite impressive design solutions for coloring functions (https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/).

@dector I agree with your assessment of that article. After I read the "coroutines do not inherit the context automatically" part in the article, I thought the author may not understand Coroutines that well. That proved a bit right after his "synchronized does do what you think it does" remark.... I do agree with the author's assesment of the debugging issues. That could be improved by JetBrains :-) About the `synchronized`: Sometimes you may really need it... I think the issue lies with the fact that

withLock

is an inline function. It should be made a regular function, so that the code inside the

withLock

lambda becomes blocking (non-suspending) again. Then, if you'd need to call some

suspend

function, you'll be forced to use something like

runBlocking

. All in all, this would make it harder to make a mistake.

I believe the issue with ThreadLocals has an official solution: https://kotlinlang.org/docs/reference/coroutines/coroutine-context-and-dispatchers.html#thread-local-data

JDK Loom is very similar of Corountines.

From my limited experience I have found that I really only need a debugger because I have not really sat down and understood the problem I have. Usually the issue stems from me not understanding the tool I am trying to work with or from just trying to move to fast.