I’ve had some time to think about this, and decided to switch back to Python. I also started my own RPC project, FrankDux, based on ZeroMQ and MessagePack for object serialization instead of Cap’n Proto.
Let’s get the obvious question out of the way - why not use Rust?
As much as I love working with Rust, the libraries that I need just aren’t available (yet), and I don’t have time to write them all. This is not a knock against Rust at all. I love the language, and still intend on contributing towards it’s evolution and ecosystem. I will continue to work to improve the Cassandra Rust driver. At the moment though, it’s just not the right tool for this job.
Why not Cap’n Proto for Python? There’s a few reasons.
For starters, Cap’n Proto manages it’s own event loop, and as a result doesn’t play nicely with drives that either use Greelets or the asyncio machinery in Python 3. Kind of a massive bummer.
Lastly, and this is a big one, there isn’t widespread Cap’n Proto support for all the languages I’d like to see. I don’t like the idea of massively limiting the languages that can access the remote server. I’d really like to be able to provide PHP and .NET libraries in particular. As a result, I decided to use libraries that are available for a ton of languages - ZeroMQ and MessagePack.
There’s a lot of things I love about Cap’n Proto, and I plan on shamelessly copying the ideas. In fact, I don’t think anything in FrankDux is an original idea. I’m attempting to combine the ease of developing HTTP servers with Bottle or Flask with the benefits of an RPC library that generates client code.
In a follow up post, I’ll be showing off an example of FrankDux in action.