Robert Jaros06/22/2019, 10:01 PM
serebit06/22/2019, 11:54 PM
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
groostav06/23/2019, 3:33 AM
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
blocks. Most have alternatives, many are not as mature as java's. Again he doesnt mention
CoroutineScope.() -> Unit
- 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.
dector06/23/2019, 3:40 AM
tl;dr his arguments are valid but just as immature as kotlinx.coroutines.But many parts of
are mature indeed! 😃
serebit06/23/2019, 3:48 AM
groostav06/23/2019, 3:50 AM
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
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
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.
dector06/23/2019, 4:21 AM
-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/).
streetsofboston06/23/2019, 1:27 PM
is an inline function. It should be made a regular function, so that the code inside the
lambda becomes blocking (non-suspending) again. Then, if you'd need to call some
function, you'll be forced to use something like
. All in all, this would make it harder to make a mistake.
Jason Ostrander06/23/2019, 1:56 PM
itnoles06/23/2019, 9:07 PM
dewildte07/15/2019, 12:04 AM
Edoardo Luppi07/01/2023, 11:35 AM