Damn this all looks really cool but im not a fan of a few of the design directions

without something in the type signature or the language to force me to deal with exceptions, i accidentally don’t handle them sometimes

John Rose et al has announced recently that java will get fibers a.k.a coroutines ;)

There is no much difference between coroutines and promises for simple stuff. Compare:

promise.then {
    it.doSomething() 
}

with

launch {
    promise.await().doSomething() 
}

This is quite a liberal example hand-crafted so that both direct usage of promise and coroutines somewhat match in readability. Coroutine benefits accrue with complex processing pipelines (do something async, then something else async, handle exceptions of multiple async actions in one place, etc).

It would require forcing type parameter to extend

Any

instead of default implicit

Any?

I have a question about the

invokeOnCompletion { ... }

. It runs regardless of the fact that the coroutine was cancelled or just completed successfully, right?

Am I the only one who thinks coroutines are kind of ... complicated?

There is no reason to argue when every person has its own use-case in mind. Different use-cases are better suited for different solutions and tools. For those who say “ReactiveX is enough” I’d suggest to look at coroutine-based #ktor routing and try to figure out how ReactiveX would have been of any help there 😉

for JVM, I strongly recommend Quasar http://blog.paralleluniverse.co/2015/05/21/quasar-vs-akka/ for concurrent programming

It's an Android app, I'm doing some async network requests and then I'm manipulation the UI. The network requests can throw `IOException`s or `HttpException`s so I need to catch them, otherwise the app will crash.

Hi everyone. Do anyone know parallel sequence library based on coroutines?

I'm curious what is the difference between lightweight threads and threads? I haven't really played with Qasar and I'm just starting to play with coroutines. What makes them less expensive? Are they just a better abstraction? Are they backed and distributed to traditional threads?

@gildor you've done the retrofit couroutine library. would you consider making one for okhttp?

@kirillrakhman I've written some kotlin-ish pseudo code here, I'd really appreciate you taking a look https://gist.github.com/Groostav/7e89dde503909a13d9ac21cd3c0f4fa2

is there a way to do something like this?

suspend val text = readFromFile()

are there any docs on coroutines performance? In particular, I’m trying to understand why nested suspending functions aren’t significantly more expensive than nested future-returning functions, due to the need to recreate the method stack on every resumption.

and are there any reasons why kotlin coroutines should have less overhead than quasar?

The other difference in implementation details concern state spilling. Quasar spills stack to heap only when suspension does happen. Kotlin spills the stack to heap before every invocation of

suspend fun

(this is covered in the spec quite well) in anticipation of suspension, even if that invocation will decide not to suspend. So here is the full table of differences:

spill on suspend        restore on resume
Quasar            LAZY                    EAGER
Kotlin            EAGER                   LAZY

You can interpret it in this way: Quasar is optimised for the code that rarely suspends, while Kotlin coroutines are optimised for the code that often suspends. This properly of Kotlin coroutines is not an accident, since they were originally optimised for an efficient implementation of

generateSequence/yield

pair that should work almost as fast as a manual implementation of the

Sequence

. However, we have a lot of room to tweak those performance trade-offs in future updates (even without breaking compatibility) as we get more data on how coroutines get actually used in the wild.

You can ask question and reply to it yourself 🙂 I think that explanation like this should be stored on something more durable than Slack channel with message limit…

suspend fun RedisAsyncConnection<String, String>.getAsync(key: String): String = suspendCoroutine { cont -> cont.resume(this.get(key).get()) }

Seems a similar topic has been discussed this morning. Hope it will be implemented sooner. 🙂

what is the reason for

suspend

not to be applicable on read-only (

val

) property ?

@pawel.barszcz: You can implement that two-way logic easily if you need it. And much more. Here is an example impl: https://github.com/Kotlin/kotlin-coroutines/blob/master/examples/generator/generator.kt

@gildor I'm playing around with retrofit coroutines and I noticed that the following trivial program never terminates. any ideas?

fun main(args: Array<String>) = runBlocking(CommonPool) {
    val result = service.someCall().awaitResponse()
    println(result)
}

You can implement retry with Retrofit and Okhttp using interceptors, so it’s possible to do for each instance of OkHttpClient

@kirillrakhman I’ve commit first draft of okhttp library, not published yet, I’m on vacation now, maybe later - https://github.com/gildor/kotlin-coroutines-okhttp Also I investigate what can I do with WebSockets API of OkHttp and coroutines.

the API for both projects'

Call

type is unchanged from the .0 release to the current minor release with regard to what it takes to adapt

try

val Cached = Executors.newCachedThreadPool().asCoroutineDispatcher()

class Foo {
    fun doBlocking(): Any {
        Thread.sleep(1000)
        return Any()
    }
}

suspend fun Foo.doAsync(): Any { 
    return async(Cached) {
        doBlocking()
    }.await()
}

@groostav with

kotlinx-coroutines-jdk8

you can write something like:

val coercedResult = future { 
    try { result.await() } 
    catch(ex: Throwable) { 
        Thread.handleUncaughtException(ex)
        emptyList() 
    } 
}