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

Cap’n Proto

capnproto.org

Post reply on HN
Print view View original

101–110 of 194 posts

Re: Cap’n Proto

#101

Post by e12e »

aidenn0 wrote: post #90
nemo1618 wrote: post #83

Earlier quoted context omitted.

Nitpick: I think you meant "&c". The t is superfluous.

Interesting; I've always written &ct, which wikipedia informs me is considered "archaic" Thanks for that note, it will save me one character of typing 3 years from now when I've finally broken the muscle memory of the old way :)

Wikipedia probably mentioned it, but & is a combination of "e" and "t", or "et" - french (or perhaps latin?) for "and". Thus &c is short for "etc", or "et cetera". I wasn't aware of the form "&ct", I presume it stands for "ET CeTera", but I'm not entirely clear on why that extra "T" would ever make sense. I doubt anyone ever used "etct"?

Re: Cap’n Proto

#102

Post by crossroads091 »

oneloop wrote: post #32
kentonv wrote: 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…

What a great pitch, that website is. I don't even understand what it is, but I'm stocked.

"Stoked". Sorry for the nitpick.

Re: Cap’n Proto

#103

Post by jasonfsmitty »

izacus wrote: post #96
kentonv wrote: post #20

Earlier quoted context omitted.

> platform inconsistencies like 32/64 bit, In terms of data layout, 32-bit vs. 64-bit architecture only really affects pointer size. But Cap'n Proto does not encode native pointers (that obviously wouldn't work), so this turns out not to matter. > endianness, It turns out almost everything is little-endian now. Also, big-endian architectures almost always have efficient instructions for loading little-endian data. So…

> In terms of data layout, 32-bit vs. 64-bit architecture only really affects pointer size. But Cap'n Proto does not encode native pointers (that obviously wouldn't work), so this turns out not to matter. Unless you're programming in C or C++ (or using a library from them), where size of int, long, etc. may change depending on architecture and compiler.

The integer types are all specifically sized, e.g. int8, int32, etc. Same thing for unsigned integers.

https://capnproto.org/language.html#built-in-types

Re: Cap’n Proto

#104

Post by wvh »

kentonv wrote: 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…

Slightly off-topic but it's good to see after all these years that companies like Microsoft (and Apple?) have to make a serious attempt to embrace the open-source community or miss out on a lot of cool new software and developers. Times have changed somewhat; the mantra used to be "doesn't work on Linux", while nowadays we've got a lot more heterogeneous environment.

Re: Cap’n Proto

#105

Post by StavrosK »

pjscott wrote: post #30
Cyph0n wrote: post #5

For some reason, the banner (infinitely faster?), name, and introductory FAQ-style responses made me think the whole thing is a joke - similar to Vanilla JS [1]. Anyways, it seems like a cool project, so I'll be sure to follow its development closely. [1]: http://vanilla-js.com/

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

Like Flask.

Re: Cap’n Proto

#106

Post by mrfusion »

I hate to ask but can anyone explain this like I'm from 2000?

I guess it's a way to send data to your front end java script but not use json and this compresses it so it's faster? How much better than using json is it?

Re: Cap’n Proto

#107

Post by [deleted] »

DonHopkins wrote: post #88
cmrdporcupine wrote: post #53

Earlier quoted context omitted.

ARM is bi-endian but my understanding is almost everybody is running it little-endian these days.

The MIPS is bi-endian, and it's referred to as SPIM when driving backwards. For some reason, Sun never got around to making a bi-endian version of SPARC called CRAPS. Speaking of Sun, I have a confession to make: I'm bi-stellar. I love both Star Wars and Star Trek. [1] https://chortle.ccsu.edu/AssemblyTutorial/Chapter-15/ass15_4...

[deleted]

Re: Cap’n Proto

#108

Post by heavenlyhash »

kentonv wrote: post #47
socmag wrote: post #45

Earlier quoted context omitted.

It sounds really well designed. Great job Cap'n Proto, I've been following your work for some time! I've also built another message format recently (yes I know, they are never ending). It can't do everything Cap'n Proto can do, although it shares a lot of the same values. One thing I chose to do is to have order preservation on types, which can be very useful. It does mean that the wire format is largely BE though. A…

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 as a pair (with explicitly language agnostic schema definitions -- which seems to be a sticking point for most of the json schema strapons).

Re: Cap’n Proto

#109

Post by striking »

mrfusion wrote: post #106

I hate to ask but can anyone explain this like I'm from 2000? I guess it's a way to send data to your front end java script but not use json and this compresses it so it's faster? How much better than using json is it?

It lets you put data on the wire, in a structured format, right out of memory. Asking the question "how much faster is it" isn't even valid here, because it skips the usual serialization process.

Cap'n Proto generates you some code that contains some data structures. You put data into these structures, and they will automatically be in the right shape to put directly on the wire. And then that data can be pulled right off the wire and right into memory and be fully ready to access, with no intermediate step.

It's, in a sense, infinitely faster than JSON serialization or deserialization. Because it doesn't even perform any serialization. It's just data.

There are some other tricks at play here, but I won't go into them. This is plenty cool.

Re: Cap’n Proto

#110

Post by floodyberry- »

wtbob wrote: post #57
kentonv wrote: post #37

Earlier quoted context omitted.

Big-endian vs. little-endian is an ancient flamewar that isn't going to go away any time soon, but sure, let's argue. Once you've spent as much time twiddling bits as I have (as the author of proto2 and Cap'n Proto), you start to realize that little endian is much easier to work with than big-endian. For example: - To reinterpret a 64-bit number as 32-bit in BE, you have to add 4 bytes to your pointer. In LE, the poi…

> To reinterpret a 64-bit number as 32-bit in BE, you have to add 4 bytes to your pointer. In LE, the pointer doesn't change. But one shouldn't do that very often: those are two different types. The slight cost of adding a pointer is negligible. > Just about any arithmetic operation on integers (e.g. adding) starts from the least-significant bits and moves up. It's nice if that can mean iterating forward from the sta…

Floating point isn't legible either, nor are are bitfields, opcodes, instruction formats, etc. That's why we use computers to do the 'right thing' and format the data if we need to read it.

I don't have a preference for either one, but using little-endian when most/every processor you will be targeting supports it makes more sense than using big-endian + extra work on x86 just so you can read it with less effort in a memory dump.

Post reply on HN