Live data from Hacker News

Cap’n Proto

capnproto.org

111–120 of 194 posts

Re: Cap’n Proto

#111

How do you pronounce the name? If libreoffice is bad.. This name is absolutely impossible. Is it captain? Is it cap+n+proto? A lot of collaboration is verbal - people sit around and talk about stuff. I don't know if it is a fun take on an American word... But it is impossible to use in the rest of the world. I really wish you would call it something else... Unless it is personal for you :(

> How do you pronounce the name?

More importantly, how do you Google for it?

Re: Cap’n Proto

#112
post #47

Earlier quoted context omitted.

I haven't looked at Ion before, but it appears to be similar to BSON or Msgpack in that it's a binary format that encodes field names as textual identifiers, to be "self-describing" and avoid the need for an external schema. I generally like schemas, because I like static typing. Of course, static types vs. dynamic types are another ancient flamewar and I'm unlikely to cover any new ground by stating arguments here.…

I like schemas for validation and strong types. I also like self-describing systems when all goes to hell and I'm debugging either my own protocols or someone else's. I have this crazy idea that there's a middle ground: self-describing and schemas? We can kind of glue this together (there's lots of json schemas floating around out there now, it seems), but it would be awfully interesting to see these well-supported a…

http://cbor.io

Re: Cap’n Proto

#113

How do you pronounce the name? If libreoffice is bad.. This name is absolutely impossible. Is it captain? Is it cap+n+proto? A lot of collaboration is verbal - people sit around and talk about stuff. I don't know if it is a fun take on an American word... But it is impossible to use in the rest of the world. I really wish you would call it something else... Unless it is personal for you :(

> How do you pronounce the name? More importantly, how do you Google for it?

At $dayjob we use capnproto as our primary interchange format. I google for 'capnp'.

Re: Cap’n Proto

#114
post #99
post #31

> The Cap’n Proto encoding is appropriate both as a data interchange format and an in-memory representation, so once your structure is built, you can simply write the bytes straight out to disk! Eh, I'd rather pay the cost of serialisation once and deserialisation once, and then access my data for as close to free as possible, rather than relying on a compiler to actually inline calls properly. > Integers use little-…

> > Integers use little-endian byte order because most CPUs are little-endian, and even big-endian CPUs usually have instructions for reading little-endian data. > sob There are a lot of things Intel has to account for, and frankly little-endian byte order isn't the worst of them, but it's pretty rotten. Writing 'EFCDAB8967452301' for 0x0123456789ABCDEF is perverse in the extreme. Why? Why? Little endian means that a…

AFAIK, POWER has supported LE for a while and at least linux on Power has moved to LE by default.

Re: Cap’n Proto

#115
post #11

Hi all, Cap'n Proto author here. Thanks for the post. Just wanted to note that although Cap'n Proto hasn't had a blog post or official release in a while, development is active as part of the Sandstorm project ( https://sandstorm.io ). Cap'n Proto -- including the RPC system -- is used extensively in Sandstorm. Sandboxed Sandstorm apps in fact do all their communications with the outside world through a single Cap'n…

I recently ran into flatbuffers https://google.github.io/flatbuffers), which claims the same no-serialization step. Curious how the two compare?

Re: Cap’n Proto

#116
post #30

Earlier quoted context omitted.

The best jokes in software usually have running code. The best of the best are practical.

Like Flask.

It was a joke aimed at Bottle, right? And now it's probably the second most popular Python web framework. Armin knows his shit.

Re: Cap’n Proto

#117
post #29
post #24

Earlier quoted context omitted.

I'm wondering how it compares to proto3, which I understand is a fairly large change to the original protobuf.

Proto3 is not a large change. In fact it shares most of its code with proto2, as I understand it. The underlying encoding is the same. Proto3 removes some features from proto2 which were deemed overcomplicated relative to their value (unknown field retention, non-zero default values, extensions, required fields) and adds some features that people have wanted for a long time (maps). But all of these features are thing…

proto2 has maps, but like proto3 they aren't maps, they're an randomly ordered sequence of key value pairs ugh.

Re: Cap’n Proto

#118

How do you pronounce the name? If libreoffice is bad.. This name is absolutely impossible. Is it captain? Is it cap+n+proto? A lot of collaboration is verbal - people sit around and talk about stuff. I don't know if it is a fun take on an American word... But it is impossible to use in the rest of the world. I really wish you would call it something else... Unless it is personal for you :(

> How do you pronounce the name? More importantly, how do you Google for it?

It's pronounced "cap enn proto". Cap'n is a contraction, you just leave sounds out of the fully expanded word.

you can search for cap'n proto in any number of ways, including its literal name [ cap'n proto ] or [ capn proto ] or [ captain proto ].

Re: Cap’n Proto

#119

To get an overview of the area of binary interchange formats that are language agnostic, the author of Cap'n Proto does a good job in this: https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-... "Protocol Buffers" has been the go-to for a long time but there are more options now. For uses where serialization/deserialization CPU time is a concern, it seems to really a question of Cap'n Proto versus flatbuffer…

When we had to choose a few months back, we picked Cap'n Proto over flatbuffers mainly over the fact that we liked the API better. I couldn't retrieve my notes from back then so I sadly can't point out. In any case, we never looked back.

Re: Cap’n Proto

#120

To get an overview of the area of binary interchange formats that are language agnostic, the author of Cap'n Proto does a good job in this: https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-... "Protocol Buffers" has been the go-to for a long time but there are more options now. For uses where serialization/deserialization CPU time is a concern, it seems to really a question of Cap'n Proto versus flatbuffer…

When we had to choose a few months back, we picked Cap'n Proto over flatbuffers mainly over the fact that we liked the API better. I couldn't retrieve my notes from back then so I sadly can't point out. In any case, we never looked back.
Post reply on HN