Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cap'n Proto 0.9

capnproto.org

Post reply on HN
Print view View original

11–20 of 38 posts

Re: Cap'n Proto 0.9

#11

Post by chii »

richieartoul wrote: post #4
hamandcheese wrote: post #3

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…

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 polici…

> annoyingly, opinionated about the wrong things.

what's what opinions are - they necessarily must be wrong to some people. Otherwise, it'd just be called facts!

Re: Cap'n Proto 0.9

#12

Post by aseipp »

jchw wrote: post #8
asimpletune wrote: post #6

Earlier quoted context omitted.

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 abo…

It's fine if most implementations of RPC are Level 1, even the main C++ bindings; due to the design of the protocol there only needs to exist a single Level 4 implementation written in any language, and all other implementations can then piggyback on it for their own needs beyond Level 1 (so cap proxying, etc. all come "for free" once someone does that.) I've mentioned Level 4 support to Kenton a while back and the basic answer was "I haven't needed it so it's not done." It's not intended for there to be a Level 4 implementation in every language or anything.

The biggest issue is undeniably that the language maturity isn't quite as solid as the alterntaives. You've got C++, Rust, Python, C#, maybe one or two others. Only C++ is first class. So gRPC and Protobuf win here. But the actual RPC design and IDL design of Cap'n is solid and way more well engineered than the alternatives, IMO.

I have no opinions on the ZeroVer thing. Cap'n Proto is very stable in my experience but I see why others would raise their eyebrows.

Re: Cap'n Proto 0.9

#13

Post by ocdtrekkie »

jchw wrote: post #8
asimpletune wrote: post #6

Earlier quoted context omitted.

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 abo…

FWIW, Sandstorm has been using Cap'n Proto since 2014, and I don't think anything done with Cap'n Proto has really broken it since, despite Cap'n Proto development largely having moved on to support Cloudflare Workers development.

With it being fundamental to Cloudflare Workers at this point, you should assume it's support will be solid for at least as long as Cloudflare Workers is a significant part of Cloudflare's business.

Re: Cap'n Proto 0.9

#14

Post by setr »

chii wrote: post #11
richieartoul wrote: post #4

Earlier quoted context omitted.

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 polici…

> annoyingly, opinionated about the wrong things. what's what opinions are - they necessarily must be wrong to some people. Otherwise, it'd just be called facts!

Having an opinion is not the same as having a good opinion. There’s a range of quality to the matter

Re: Cap'n Proto 0.9

#15

Post by dpwm »

caturopath wrote: post #9
hamandcheese wrote: post #3

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…

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.

> You can work with results without actually having the results, e.g. before the results exist.

This results in cool things like promise pipelining. It is very interesting how it can simplify interface design, and there are examples on the RPC page[0].

[0] https://capnproto.org/rpc.html

Re: Cap'n Proto 0.9

#16

Post by dpwm »

jchw wrote: post #8
asimpletune wrote: post #6

Earlier quoted context omitted.

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 abo…

> It has yet to escape the ZeroVer versioning scheme and produce a “stable” API.

Having worked with it over years, the API stability is there. Backwards compatibility is given very strong emphasis, , even with early versions.

> Maturity for languages other than C++ can be a bit spotty.

The language support is a pain at times, especially as the more esoteric language support tends to be built with a specific use case in mind and may not use and implement all the features of the protocol in sometimes undocumented ways.

People can and do write implementations and contribute to existing ones. The C++ and its Javascript and Python bindings work well enough for many use cases. The Rust ones are also fine. There are probably others that have good support now, too.

> The RPC protocol is cool, but apparently most of it was never implemented. The C++ implementation only implements “level 1.”

The RPC protocol is perfectly usable, just not for the higher levels – which all do things not found in other RPC systems. Level 2 can be trivially implemented between client and server at the app level, as anything similar would need to be in any other RPC system. Level 3 sounds way beyond standard RPC needs.

Re: Cap'n Proto 0.9

#17

Post by dureuill »

jchw wrote: post #8
asimpletune wrote: post #6

Earlier quoted context omitted.

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 abo…

While it is technically not 1.0, I have yet to see a breakage and I have been using it since 0.7.

The language maturity one, I can concur though. The rust implementation has been fine, but pycapnp was plagued with memory leaks until recently, and curre tly has performance problems[1] that makes it unsuitable for my use case.

As for the level 2+ protocol, it looks cool on paper, but it looks like a lot of added complexity to address an advanced use case.

The language itself has generics and sum types, which makes it much better at modelling the problem domain than protobuf.

[1]: https://github.com/capnproto/pycapnp/issues/256

Re: Cap'n Proto 0.9

#18

Post by studentrob »

appleflaxen wrote: post #2

I 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!

You mean sandstorm?

https://sandstorm.io/

Edit: oh you do mean sandcats..

https://docs.sandstorm.io/en/latest/administering/sandcats/

Re: Cap'n Proto 0.9

#19

Post by edoceo »

setr wrote: post #14
chii wrote: post #11

Earlier quoted context omitted.

> annoyingly, opinionated about the wrong things. what's what opinions are - they necessarily must be wrong to some people. Otherwise, it'd just be called facts!

Having an opinion is not the same as having a good opinion. There’s a range of quality to the matter

The point is that "good" and "quality" is subjective and highly dependent on use-case.
Post reply on HN