https://kotlinlang.org logo
Channels
Powered by
#coroutines
  • p

    pniederw

    01/20/2017, 11:18 PM
    apart from that, I have an event handler for incoming requests, and a future-based http client for outgoing requests.
  • o

    orangy

    01/20/2017, 11:18 PM
    I mean, there is probably a pain somewhere in this API 🙂 Thinking about collecting use-cases and helping to get rid of that pain.
  • p

    pniederw

    01/20/2017, 11:18 PM
    the main pain is future-based programming in java
  • o

    orangy

    01/20/2017, 11:18 PM
    Not specifically in your proprietary stack, but in general
  • o

    orangy

    01/20/2017, 11:18 PM
    Okay, I got it. That pain is well-known 🙂
  • p

    pniederw

    01/20/2017, 11:18 PM
    e.g. all the limitations of java lambdas
  • k

    kevinherron

    01/20/2017, 11:19 PM
    @orangy thanks for mentioning ktor 🙂 now i don’t have to wonder about doing that
  • p

    pniederw

    01/20/2017, 11:19 PM
    deciding whether callbacks need to be nested because a previous result is required further down the line
  • o

    orangy

    01/20/2017, 11:19 PM
    @kevinherron what do you mean? doing what?
  • k

    kevinherron

    01/20/2017, 11:19 PM
    (had idea to build a Spark-like web framework on netty using suspend all the way to core)
  • k

    kevinherron

    01/20/2017, 11:20 PM
    your handlers are just as clean as they are in Spark, but everything is async because of coroutine magic 🙂
  • p

    pniederw

    01/20/2017, 11:20 PM
    inability to throw checked exceptions from lambdas, effectively final, etc.
  • o

    orangy

    01/20/2017, 11:20 PM
    @kevinherron come to #ktor and help make it better 🙂
  • o

    orangy

    01/20/2017, 11:21 PM
    but coroutines are not there yet…
  • p

    pniederw

    01/20/2017, 11:21 PM
    with kotlin, and async/await in particular, most of this pain just disappears
  • k

    kevinherron

    01/20/2017, 11:21 PM
    not yet, but if you’re planning on it, then the world doesn’t need yet another web framework
  • o

    orangy

    01/20/2017, 11:21 PM
    the Kotlin world needs some open source love from PRs and adoption.
  • k

    kevinherron

    01/20/2017, 11:22 PM
    but a web microframework seems like a particularly good use case for coroutines. (shrug)
  • p

    pniederw

    01/20/2017, 11:23 PM
    by now, the biggest pain point is probably that I can only await() inside library-provided control abstractions that are marked as inline
  • o

    orangy

    01/20/2017, 11:23 PM
    I suggest moving this particular discussion into #ktor
  • p

    pniederw

    01/20/2017, 11:23 PM
    and debugging is still a problem of course
  • o

    orangy

    01/20/2017, 11:24 PM
    Debugging is of course the main thing to work on
  • o

    orangy

    01/20/2017, 11:24 PM
    Some IDE features as well, but debugging is primary issue
  • p

    pniederw

    01/20/2017, 11:24 PM
    yeah, anything that can be done there would be huge
  • k

    kevinherron

    01/20/2017, 11:24 PM
    agreed
  • o

    orangy

    01/20/2017, 11:25 PM
    There are lots of things to do in debugging, like stack rebuilding, suspend-aware stepping, etc
  • p

    pniederw

    01/20/2017, 11:26 PM
    that might be another good reason for moving from futures everywhere to suspend functions
  • k

    kevinherron

    01/20/2017, 11:26 PM
    i’ve already made the technical decision to use kotlin coroutines in this new development i’m working on, but debugging support for coroutines will sure help me defend my choice 🙂
  • o

    orangy

    01/20/2017, 11:27 PM
    We welcome you, brave souls! 🎉
  • p

    pniederw

    01/20/2017, 11:28 PM
    wait, who isn’t running kotlin co-routines in production? (low traffic admittedly)
1...266267268...571Latest