1. 8
  1.  

  2. 3

    I work on finagle professionally, happy to answer questions anyone has about it.

    1. 1

      My impression has been that Finagle’s quite slow-moving - it took a while for a 2.10 release and there’s still no 2.11 release AFAICS - which put me off using it in my projects. Are there plans to address this?

      What’s the way forward for Future functionality? The Scala ecosystem seems to have now converged on scala.concurrent.Future (e.g. Akka no longer has its own Future), leaving Finagle a bit off to the side. Will Finagle move to use standard Scala futures, continue to maintain its own Future variant, or what?

      1. 2
        scala 2.11

        Finagle is slow-moving on scala version compatibility because twitter is internally still on 2.9.2. We’re going to move to 2.10 shortly, but we might be the largest production user of scala in the world, and we’ve been doing it for a long time, so there’s a lot of code which basically looks like scala 2.7 or scala 2.8 code which needs to be upgraded. So it’s not a business priority for us to move to 2.11 immediately.

        As far as why we haven’t just changed our sbt files to say “cross publish 2.11”, our hands are tied by the libraries that we use. Specifically, we used specs for many of our tests, and specs has been deprecated for a while. Notably, there aren’t 2.10 or 2.11 versions of specs. We had three choices in front of us–publish our own specs, switch to specs2, or switch to scalatest. We find scalatest more pleasant to work with, and in general has better compilation speeds, so we’ve consolidated on scalatest. However, it slows migration work.

        Our strategy for a while was to lazily move tests from specs to scalatest as we wrote more tests, sort of taking a “leave the campground cleaner” rule. However, 2.11 was published, and taking a look around, there was no end in sight. Our code had too many tests ;) Luckily, some members of the community decided to take matters into their own hands.

        util specs => scalatest
        finagle-core specs => scalatest

        The fight isn’t over, but we’re making progress.

        TL;DR: Twitter doesn’t care because we’re pegged against 2.9.2 for at least a few months, the community is working on it.

        slow moving

        Finagle is not particularly slow moving, but there are only five of us, so the areas in which we’re making progress might not be of tremendous interest to you. There are a few pretty interesting things going on, notably:

        cleaning up exceptions
        adding a new session-layer protocol called mux
        managing session-level leases to avoid latency from gc
        logical name => physical address abstraction for service discovery
        experimental schedulers
        experimental loadbalancers

        future compat

        For future functionality, twitter worked with scala to make sure that their futures were compatible with twitter futures. As soon as we can drop 2.9.2 (which doesn’t have scala futures) we’re going to change twitter futures to extend scala futures. However, we’re not going to drop twitter futures. There are a few differences between in the implementations. Off the top of my head:

        1. twitter futures are scheduled by a global scheduler, so we can be pretty smart about keeping work in the same thread (avoiding context switches) by default, but also allowing work stealing, etc.
        2. Because twitter futures are better at avoiding context switches, we’ve found that our default schedulers make most of our workflows much faster than our scheduler which mimics normal use of scala futures.
        3. twitter futures support interrupts, which let you signal that you’re no longer interested in the result of a Future.
        4. twitter futures support threading context through their execution context–scala futures have an execution context explicitly so that you can do this, but they haven’t yet (not sure why). This is useful for things like threading tracing information. You could also in theory thread stack traces, and later stitch together a sensible asynchronous stack trace.

        There are a few other things I can think of, like more sophisticated manipulation of the future dependency graph (you can detach dependent Promises, etc, which is useful for implementing future caches correctly without space leaks), but they get more esoteric.

        TL;DR Twitter futures are definitely not going away. But we will extend the scala future trait when we’re off 2.9.2.