Aside from the speed benefits, are there any other major advantages of Cap’n Proto?
I’ve been using grpc/protobuf with Java and Scala. Overall I like it, but the grpc Java library does feel like it comes with a lot of opinions baked in. As an example, I was looking in to implementing automatic retries on the client side for certain classes of error. Grpc Java has some experimental retry support, but it seemed tightly coupled to their also-opinionated way of doing service discovery. I can see why you might want the server to inform clients how to do retries, keepalives, etc. But for less sophisticated operations (read: me) it is frustrating and over complicated. Why can’t I just specify a retry policy when creating a client stub?
Still, it’s better than anything else I’ve seen.
But I do long for a simpler alternative. Is that Cap’n proto? Seems like for Java there is only 3rd party support for serialization only, and not RPC.
If you're happy with protobuf but just not with gRPC, you can check out Twirp [1] and DRPC [2]. Both aim to be simpler alternatives while keeping protobuf for serialization. Their development is Go focused though.