Or maybe I can help with making common module with expected blocks for coroutines features and platform-specific modules for them for js and jvm?

Hey all - satisfying my curiosity here... is there any way to

suspend val

(say, with

get() {}

or a delegate) at this point? I tried a few things and nothing worked, but I also wasn't sure if I was just doing it wrong. 🙂

I have started using

compile 'org.jetbrains.kotlinx:kotlinx-coroutines-android:0.19.3'

however there is some rightful so skepticism from some of my colleagues. I would like to know if it is safe to use coroutines in production. I need a professional statement fro my colleagues. I mostly use

suspend

keyword and

launch()

Anyone have already implemented delay in Kotlin/JS?

I was wondering, what's the current way to create a coroutine on JS? there are no builders if I'm not mistaken. Should I write my own oder can I just get away with making my

main

function

suspend

?

I just saw the talk by @elizarov. He mentions a second talk, is there a link to that?

in this case

async()

is function (coroutine builder) and

await

is a function in interface Deferred (returned from async()) and both of them are part of kotlinx.coroutines library, not a part of language or stdlibrary. You can write own implementations that doesn’t coupled with particular Promise/Feature implementation like in languages where async/await is part of the language

No performance difference, but a big functional one. See 😒tackoverflow: https://stackoverflow.com/questions/46226518/what-is-the-difference-between-launch-join-and-async-await-in-kotlin-coroutines

Maybe you will share this error message, otherwise it’s hard to help you

@marcinmoskala

runBlocking

and

join

all jobs with

delay

after, have

refreshList

as mocked interface, and check if being called expected x times for delay?

at this time intellij is not honoring launch{} keyword from inside main

@jw either the syntax is wrong, the imports are or the pom. I'm just trying to find a working example to paste in and tweak it from there.

Is the warning for coroutines

The feature "coroutines" is experimental

something new? I didn't notice it until today, and now all my

run

and

launch

invocations are highlighted

I've been thinking about why, while I've been interested about couroutines since kotlin 1.1 came out, I have been reluctant to actually use them in any of my projects yet. It's not because I'm concerned about the maturity of the libs. It's not because "they are still experimental", while I could use this lame excuse if asked out of the blue. It's not because of the documentation, the documents and talks from @elizarov are great It's that I remember when I first rushed to use Promises (in JS) then RxJava in my projects, I didn't have the practical experience to use them correctly and made a LOT of mistakes Coroutines do seem easier to get right, but asynchrononicity is hard no matter what. I have no practical experiences with the style of programming with channels and actors for example. So the real issue is that I lack a safe playground where I could practice all these new toys, hopefully not only with "delay()" but also simple UX, DB and network stuff. so the TLDR is that having and completing a kotlin #koans for coroutines would boost my confidence in my own ability to use them correctly!

I can't immediatly switch to kotlin on my work project. So I started a side project last june with kotlin and coroutines. And it's been months of refactoring, following my comprehension of coroutines! So I +1, starting coroutines immediately in a professionnal project isn't wise.

@elizarov How would you simplify that Ion integration? With cancel in consideration and that coroutine should be used instead of threads... Im not sure what parts of that implementation are necessary and what not? This is just an example, but ive seen other integrations that also do complex things for what I thought should have been simple. I wonder if they want to avoid an extra dependency, or people are still not grasping how to do the integration properly... maybe a set of guidlines would have been good in such a case...?

what is the overhead of withTimeout? just one timer for the cancel delay?

thanks @gildor

this is probably not coroutine specific, but is it possible to detect blocking code? i have a withTimeout block, with a one second timeout, and sometimes it takes 5 seconds instead. I think that the lib that I'm using is reconnecting and that its blocking when it does that. but it would be very useful to get a stacktrace of the blocking method in that case

notice that you will have all 100 coroutines running in parallel, just not concurrently

You don’t need to explicitly do

join

if you rely on parent/child rels to split one large task into parallel subtasks. So, to do

mySuspendingTask

100 times in parallel you can just do:

fun main(args: Array<String>) = runBlocking {
    (0..100).forEach { launch(coroutineContext) { mySuspendingTask() } }
}

Now you are explicit about parallelism — you’ll launched concurrent subtask. No worries, since they are very cheap. You can run millions. You outer job (in this case — main) automatically waits for all the children to complete.

Btw,

.map { it.await() }

seems to be a common pattern. We might want to introduce extension like

.awaitAll()

for it.

In my case it's a network request, that's why I want to limit the amount of concurrent requests

BTW, how do I limit the number of concurrent children my coroutine might have? The suggested way of using a limited thread pool can't be used as-is since I have to use the parent context to have the parent-child relationship.

fun main(args: Array<String>) = runBlocking {
    (0..100).forEach { 
         launch(coroutineContext) {   // <- limit the number of concurrent threads ?
             mySuspendingTask() 
         } 
    }
}

Limited parallelism seems to be quite a common pattern, so here is a bunch of ideas on what we can improve: https://github.com/Kotlin/kotlinx.coroutines/issues/172

@gildor The solution could also be used for

onPermissionsRequestResult

, which has been a real pain for Android developers, given the count of permissions helper libraries

Hi all :kotlin: Has someone already noticed/reported that

suspend

doesn’t work with

typealias

? Example:

typealias MyType = (Any) -> Any
fun testFunction(block: suspend MyType) {}
//                      ^^^^^^^
// Modifier 'suspend' is not applicable to 'non-functional type'