Robert Jaros
06/22/2019, 10:01 PMserebit
06/22/2019, 11:54 PMsynchronized
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 intogroostav
06/23/2019, 3:33 AM-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.dector
06/23/2019, 3:40 AMtl;dr his arguments are valid but just as immature as kotlinx.coroutines.But many parts of
kotlinx.coroutines
are mature indeed! 😃serebit
06/23/2019, 3:48 AMgroostav
06/23/2019, 3:50 AMI'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.dector
06/23/2019, 4:21 AMasync
-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/).streetsofboston
06/23/2019, 1:27 PMwithLock
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.Jason Ostrander
06/23/2019, 1:56 PMitnoles
06/23/2019, 9:07 PMdewildte
07/15/2019, 12:04 AMEdoardo Luppi
07/01/2023, 11:35 AM