My 5 cents here. :slightly_smiling_face: **Articl...

# coroutines

[dector]

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.