Scala Future and Promise vs. Reakt Future and Promise

QBit overlaps with Akka. Reakt promise lib overlaps with Akka Futures/Promises. There is nothing quite like the Reakt Reactor in Akka or Scala promise/future lib.

First there are many similarities

QBit and Reakt were heavily inspired by Vert.x and the JavaScript libs for promises. Since Java is not JavaScript when trying to model how JavaScript handles async calls, some constructs were needed.

Turns out these constructs mirror, somewhat, what you see in the Akka/Scala world. The futures lib was moved from Akka into Scala proper and has evolved over time as well.

A rough mapping

• Scala Future -> Reakt Callback / Promise
• Scala Try -> Reakt Result
• Scala Promise -> Reakt Promise / Callback
• Scala Option -> Reakt Expected

Where a Scala Future has a map function, a Reakt Promise has a thenMap method. Reakt tends to use JavaScript constructs like any, and all instead of for comprehension. A Scala future filter would map to a Reakt Promise.thenExpected/filter (perhaps Promise should have a filter but it does not). A Scala future recoverWith / recover would map to a Promise.thenExpected/expected.orElse (perhaps Promise should have a recoverWith but it does not).

In the Reakt world, a promise is more like a Scala future most times. Where clients tend to work with Futures in Scala, they work with Promises in Reakt (which again mirrors the JavaScript constructs).

It should be easy to convert from a Reakt Promise to a Scala Promise of Future, and it should be easy to do this implicitly. The first thought it to add method asReaktCallback and asReaktPromise to Scala Promises. Then add asScalaFuture and asScalaPromise to Reakt Promises, a bit like the Java collection lib integration with Scala.

Then for complete seamless write once use in both places, you may want an implicit converter to convert from Reakt Promise to a Scala future.

Where Scala has Await, Reakt has blockingGet and blockingGet with a Duration on the Reakt Promise.

Where Scala has ExecutionContext, Reakt has a Reactor, which is quite a bit more than an ExecutionContext. Make a Reactor appear as an ExecutionContext would be nice either through implicits or explicits (asExecutionContext). The Reactor is a key element of Reakt. The Reactor is a class that enables: callbacks that execute in caller's thread (thread safe, async callbacks), tasks that run in the caller's thread, repeating tasks that run in a caller's thread and one shot after time period tasks that run in the caller's thread. The reakt Reactor is a lot like the QBit Reactor or the Vert.x context. It allows you to enable tasks that run in that actors or verticles thread and simplifying integration with 3rd party IO libs and reducing the number of threads you spawn. The reakt Reactor creates replay promises. Replay promises execute in the same thread as the caller. They are "replayed" in the callers thread.

Reakt integration libs

Reakt has integration libs for Cassandra, Guava, Vert.x, and more. Our intention is to create one for Scala as well so you can easily use the Reactor from Akka, which has merit on its own, and as we build out Reakt integration with async libs, we can use those from Akka/Scala.

Also, Reakt has a nice abstraction for streams and async Circuit breakers.

Also if you wanted to write a lib that worked well with Java and Scala's Future and Promises to interact with a 3rd party lib like Kinesis, DynamoDB, etc., given Scala's implicit conversions and Reakt's similar constructs for Promises, you would think Reakt would be a nice lib to target.