3 ms·

The type system woes are quite legit. I wonder how many of these were improved in FlatBuffers. Which has a ton of other good things going for it, chiefly ideall

The type system woes are quite legit. I wonder how many of these were improved in FlatBuffers. Which has a ton of other good things going for it, chiefly ideally less serialization demands. Once you start doing rpc, the demand goes so up. Cap'n'Proto's ability to return & process future values is such an exciting twist, that melds with where we are with local procedure calls: they return promise objects that we can pass all around while work goes on. Kenton popped up a couple months ago to mention maybe finding time for mutli-party support, where I can for ex request say the address of a building & send the future result to another 3rd party system. Now this is less just a way to serialize some stuff, & more a way to imagine connecting interesting systems.

the-alchemist 4y ago
Is Cap'n'Proto [0] as awesome as it sounds? Anyone have any first-hand experience and can speak on it? Thanks! [0]: https://capnproto.org/ https://capnproto.org/
- ChadNauseam 4y ago
  I've used Cap'n'Proto for a work project, and aside from not-always-amazing language compatibility it really is awesome. It's what I wish Protobufs was. The performance improvements don't matter much to me, the biggest thing for me is the type system fixes most of the mistakes that are mentioned in this article.
- avinassh 4y ago
  is it possible to use this with gRPC? edit: seems, not possible as of now - https://github.com/capnproto/capnproto/issues/478 https://github.com/capnproto/capnproto/issues/478
avinassh 4y ago
I was looking to Cap'n Proto's page and they say: > Cap’n Proto gets a perfect score because there is no encoding/decoding step. How do they achieve this?
- zarzavat 4y ago
  It’s an untruth. There is a validation step of course, which means that there is a decoding step. There is no encoding step because the wire format is the same as the in-memory representation.
  - kentonv 4y ago
    > There is a validation step of course No, there isn't. Not any more than there is a decode step anyway. The truth is that encoding, decoding, and validation all occur when you call the accessor methods for specific fields. If you never actually call the getter for some field, it won't be decoded nor validated at all. If you are going to be reading the entire message tree, then zero-copy is only an incremental improvement on something like Protobuf -- the use of fixed-width values may make decoding faster (or slower, in some cases). The real magic is when you want to read just one field of a 10GB file. Just mmap() the whole thing and treat it like a byte array, and it'll be efficient. Cap'n Proto will not attempt to scan the whole file, only the parts that you explicitly query. (I'm the author of Cap'n Proto.)

the-alchemist 4y ago

Is Cap'n'Proto [0] as awesome as it sounds? Anyone have any first-hand experience and can speak on it? Thanks! [0]: https://capnproto.org/ https://capnproto.org/

ChadNauseam 4y ago
I've used Cap'n'Proto for a work project, and aside from not-always-amazing language compatibility it really is awesome. It's what I wish Protobufs was. The performance improvements don't matter much to me, the biggest thing for me is the type system fixes most of the mistakes that are mentioned in this article.
avinassh 4y ago
is it possible to use this with gRPC? edit: seems, not possible as of now - https://github.com/capnproto/capnproto/issues/478 https://github.com/capnproto/capnproto/issues/478

avinassh 4y ago

I was looking to Cap'n Proto's page and they say: > Cap’n Proto gets a perfect score because there is no encoding/decoding step. How do they achieve this?

zarzavat 4y ago
It’s an untruth. There is a validation step of course, which means that there is a decoding step. There is no encoding step because the wire format is the same as the in-memory representation.
- kentonv 4y ago
  > There is a validation step of course No, there isn't. Not any more than there is a decode step anyway. The truth is that encoding, decoding, and validation all occur when you call the accessor methods for specific fields. If you never actually call the getter for some field, it won't be decoded nor validated at all. If you are going to be reading the entire message tree, then zero-copy is only an incremental improvement on something like Protobuf -- the use of fixed-width values may make decoding faster (or slower, in some cases). The real magic is when you want to read just one field of a 10GB file. Just mmap() the whole thing and treat it like a byte array, and it'll be efficient. Cap'n Proto will not attempt to scan the whole file, only the parts that you explicitly query. (I'm the author of Cap'n Proto.)