Cap'n Proto 0.9
capnproto.org
Cap'n Proto 0.9
1–10 of 38 posts
Re: Cap'n Proto 0.9
#2I am a huge Kenton Varda fan. his sandcats platform was genius. I'm happy to see it open sourced, but sad to see the development slow down.
great to see he is still pushing cap'n proto forward!
Re: Cap'n Proto 0.9
#3Aside 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.
Re: Cap'n Proto 0.9
#4Aside 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…
I also agree that the gRPCs libraries (in all languages) tend to be opinionated, and most annoyingly, opinionated about the wrong things.
That said I also haven’t found anything better either and the technology is popular enough that I stick with it and just work around the limitations.
For your specific case I highly recommend ignoring the built in GRPC retry nonsense and using the Java failsafe library retry policies instead. That has worked well for my team at least.
Re: Cap'n Proto 0.9
#5Aside 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…
>are there any other major advantages of Cap’n Proto?
Parametric type polymorphism AKA generics.
I regularly think of Cap'n Proto when working with gRPC or GraphQL, despite not ever having had the chance to use it in a real project.
Re: Cap'n Proto 0.9
#6Aside 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…
The actual language itself is very nice https://capnproto.org/language.html, and it has a bunch of really great security features. I actually think of it the other way around and don't understand why it's not used more.
Re: Cap'n Proto 0.9
#7Aside 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…
>are there any other major advantages of Cap’n Proto
There's a list at https://capnproto.org/ under "other advantages".
Re: Cap'n Proto 0.9
#8Aside 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…
The actual language itself is very nice https://capnproto.org/language.html , and it has a bunch of really great security features. I actually think of it the other way around and don't understand why it's not used more.
On paper I agree. However it does have a couple of problems:
- It has yet to escape the ZeroVer versioning scheme and produce a “stable” API.
- Maturity for languages other than C++ can be a bit spotty.
- The RPC protocol is cool, but apparently most of it was never implemented. The C++ implementation only implements “level 1.”
Cap’n Proto is undeniably cooler than Protobuf, although in practice I worry primarily about maturity and support.
Re: Cap'n Proto 0.9
#9Aside 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…
The 'cap' in Cap'n Proto is for https://en.wikipedia.org/wiki/Capability-based_security -- Cap'n Proto isn't actually an RPC system, it's a capabilities framework. You can work with results without actually having the results, e.g. before the results exist.
Re: Cap'n Proto 0.9
#10What will it take before it’s declared as 1.0?