No no, you're missing the point, it's an RPC proxy which is language agnostic. It sits along side your application as opposed to being a library that you bake in.
We can definitely improve the docs a bit on this point.
But FWIW we totally agree with you. Finagle itself is a JVM library, and that worked well enough at Twitter [insert caveats here], but a big part of the reason we built linkerd is extending that model to non-JVM / polyglot services. There's SO much good stuff in Finagle... it would be a pity to confine it just to the JVM.
Yup. I do wish there were more work done on the actual client/server side (the P and C of "RPC"), too, something Linkerd can't solve for you, and which I believe Finagle does.
So far all our work has been JSON-over-HTTP, which is not performant. We've looked at gRPC and Thrift, but we've been dreading the prospect of having to pre-declare IDL, generate language glue and write client/server setup glue for every app.
At the moment, we're closing in on using NATS as a routing proxy, fulfilling a role very similar to Linkerd. Turns out it's fast enough that you can do RPC with it, and it seems very reliable. Language bindings are good to the point where you have to write almost no glue code. You have to pick a serialization format, and I think Msgpack might work well here.
I'm curious to hear what your experience with NATS will be. We haven't played with it. I do know that a ton of the work that went into Finagle was around resilience at scale: things like backpressure, circuit breaking, and generally tolerating slow, bad, or flapping servers. Personally I would want to see that sort of thing in any RPC system before using it at scale.
We're a small shop; each of our clusters are currently a couple dozen static servers at most. So we don't really do anything at what would be considered "at scale". For us, developer ease of use and performance is a higher priority.
But we're slowly moving towards a setup where we'll likely rely on autoscaling, and where we will likely need a more robust architecture.