search

twitter / storehaus

Storehaus is a library that makes it easy to work with asynchronous key value stores
Apache License 2.0
464 stars 86 forks source link

Twitter Future vs Akka Future #273

Closed debasish83 closed 8 years ago

debasish83 commented 9 years ago

Hi,

Most of the frontend stack like Spray / Play are using Akka future but StoreHaus returns Twitter Future. Is there a way to come up with a unification ? Akka future are Scala future right now as well.

We want to use StoreHaus since it abstracts the API from the underlying data store which is critical to benchmark different stores (we are looking into HBase and Cassandra for now).

Thanks. Deb

travisbrown commented 9 years ago

There are officially supported converters between Twitter futures and Scala futures in the bijection project.

There's been some discussion of having Twitter's futures implement Scala's Future trait, but for a number of reasons this isn't trivial (or necessarily desirable). Twitter's Future doesn't require an implicit ExecutionContext on all of its combinators, for example—this is an important API difference that's closely related to the reasons that Twitter futures are better at avoiding context switches.

In the meantime, many organizations are happily using the bijection converters. There's some overhead, of course, but it's generally possible to minimize the number of places that you need to convert in such a way that it's acceptable.

johnynek commented 9 years ago

Side note: getting rid of twitter.util.Try in favor of scala.util.Try seems much easier to do, and probably worth it, if you ask me.

We could make a val Try = scala.util.Try; type Try[T] = scala.util.Try[T] in the util package object, and that would make a lot of porting easier.

It's a yak shave, but it would remove some constant friction.

travisbrown commented 9 years ago

@johnynek Agreed. We'd also want to get rid of our NonFatal if we go this route, since it's so closely related to Try.