Fibers and Actors in Kotlin with Quasar

Andrey Breslav

In the previous post we mentioned that the Quasar library now supports Kotlin, providing awesome support for fibers (lightweight threads), Go-like channels, Erlang-like actors, and other asynchronous tools.

Our friends from Parallel Universe have published a blog post that dives into details of using Quasar with Kotlin. Even in the unlikely case that multithreading doesn’t concern you much, Quasar/Kotlin integration is a great example of a “DSL” library written in Kotlin, it uses

  • data classes
  • top-level functions
  • lambdas
  • annotated expressions
  • when-expressions
  • inline functions

to build a natural-looking and efficient API, and the blog post explains it very well.


Comments below can no longer be edited.

2 Responses to Fibers and Actors in Kotlin with Quasar

  1. Olivier Binda says:

    June 4, 2015

    I’m already sold on how more fun it is to write dsl/kotlin/functionnal code compared to java/imperative code.

    But what I would really like to know is :
    What are the benefits of using quasar other RxJava ? (are there benchmarks ? )
    Are there significant performance gains ?
    And what about memory/energy/maintainability/ease of (re)-use…

    • pron says:

      June 4, 2015

      Quasar has similar performance/memory usage to RxJava or other asynchronous libraries. The advantage of using Quasar is much simpler, more understandable, easier to debug, and more familiar code. Solutions based on monadic composition, like RxJava, need to replicate existing language constructs like error handling, control flow and state. They also lose the stack context (a stack trace when using one of the asynchronous libraries is useless), while Quasar — because it uses a blocking, synchronous style — lets you use the stack, catch exceptions etc..

      While other libraries try to avoid blocking threads, and provide you with monads to help with composing callbacks, Quasar simply makes blocking threads free, by providing userspace threads, or fibers.

      Another advantage is being able to use familiar, standard APIs (like HTTP clients, database drivers etc.) — those that have been made fiber-aware, like the integration modules in the Comsat project, so it doesn’t impose much “library lock-in”, and the total adoption cost is lower.