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.

@groostav

tl;dr his arguments are valid but just as immature as kotlinx.coroutines.

But many parts of

kotlinx.coroutines

are mature indeed! 😃

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.

Four years later and the debugging point still holds true.