KEEP VS kotlinx.coroutines

KEEP: Context receivers

I'd be very interested in a comparison between scala 3 using/given and Kotlin new context receivers https://github.com/Kotlin/KEEP/blob/master/proposals/context...

This will be furthermore simplified with multiple receivers coming very soon

I’m realizing I forgot to mention the scripting proposal in the post, will add it soon.

Tfw no pattern matching. :(

I hadn't gone over the Context Receivers design proposal until now (and still doing so, so take this with a grain of salt), but the use of what is seemingly a function call(but not) to define them seems like a bad choice. I'm sure there are design constraints that pushed this option forward, but it just seems really odd and out of place in the current Kotlin language design.

I'm aware that kotlin decided against this in kotlin itself, see https://github.com/Kotlin/KEEP/issues/82.

Here's a GitHub issue going into how utterly confusing Kotlin's coroutine error handling is: https://github.com/Kotlin/kotlinx.coroutines/issues/763

Sure! runCatching catches Throwable right? Well when you cancel a coroutine it throws a CancellationException and this gets used as a signal to stop execution. runCatching stops that signal so the coroutine keeps running. Lemme find you a link real quick https://github.com/Kotlin/kotlinx.coroutines/issues/1814

Recently, a Dev helped with adding an IdlingResource dispatcher provider to help with coroutines. See https://github.com/Kotlin/kotlinx.coroutines/issues/242

According to the author of kotlinx.coroutines lib, it will try to keep the same thread if possible but not always. After my question, he updated the document of Dispatchers.IO to be like this https://github.com/Kotlin/kotlinx.coroutines/pull/3236/files This dispatcher and its views share threads with the [Default][Dispatchers.Default] dispatcher, so using `withContext(Dispatchers.IO) { ... }` when already running on the [Default][Dispatchers.Default] dispatcher typically does not lead to an actual switching to another thread. In such scenarios, the underlying implementation attempts to keep the execution on the same thread on a best-effort basis.

I think it is a great question and you can ask it on github

This is the issue I posted in GitHub https://github.com/Kotlin/kotlinx.coroutines/issues/3234 Thank you for the suggestion

DI: Dependency injection: Check out Dagger Hilt, Koin or Kodine. Architecture: Android tends to be MVVM but, MVP, MVI and some others exist. Async calls: For kotlin, coroutines. Rxjava can be used with kotlin or java. I'm not actually sure how java devs do asyn calls these days.

FlowCollector is now fun interface, and corresponding inline extension is removed (#3047).

Kotlin based, Coroutines + Flow for asynchronous.