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

131–140 of 194 posts

Re: Cap’n Proto

#131

Post by DenisM »

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…

How about first-class map / dictionary support? That is, const or log time retrieval of key-value pairs.

Right now I can only see a way to create lists, so access will be in linear time.

Re: Cap’n Proto

#132

Post by [deleted] »

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…

[deleted]

Re: Cap’n Proto

#133

Post by bascule »

kentonv wrote: post #33
lobster_johnson wrote: post #27

Earlier quoted context omitted.

I'd like to see Ruby bindings (not just serialization). We are using Go, Node.js and Ruby in production, and we have been looking to move from plain HTTP to gRPC. If Cap'n Proto is better, we might use it, but not without Ruby bindings.

I don't think anyone is currently working on Ruby bindings, but if you're interested, feel free to take it on! (Note that Sandstorm is focused on making Cap'n Proto work well for Sandstorm. We welcome contributions, but we generally don't have resources available ourselves to work on third-party feature requests unrelated to Sandstorm. That is, unless you want to pay us a bunch of money, in which case, feel free to c…

Actually there was a Capnproto project for Ruby GSoC project this year!

https://github.com/nemoNoboru/capnp-ruby

https://rubygems.org/gems/capn_proto-rpc

Re: Cap’n Proto

#134

Post by nemoNoboru »

bascule wrote: post #133
kentonv wrote: post #33

Earlier quoted context omitted.

I don't think anyone is currently working on Ruby bindings, but if you're interested, feel free to take it on! (Note that Sandstorm is focused on making Cap'n Proto work well for Sandstorm. We welcome contributions, but we generally don't have resources available ourselves to work on third-party feature requests unrelated to Sandstorm. That is, unless you want to pay us a bunch of money, in which case, feel free to c…

Actually there was a Capnproto project for Ruby GSoC project this year! https://github.com/nemoNoboru/capnp-ruby https://rubygems.org/gems/capn_proto-rpc

Yep, that's my project. Please use it and contact me if somenthing doesn't work!

Re: Cap’n Proto

#135

Post by kentonv »

adrianratnapala wrote: post #127
kentonv wrote: post #51

Earlier quoted context omitted.

Well, I could write a lot about this, but... In general, because I felt there was too much resistance to me pursuing ideas that I wanted to pursue. Google has become increasingly top-down, whereas it was fairly bottom-up when I started in 2005. That's not necessarily a bad thing, but I felt that I personally would be happier running a startup where I could call the shots. FWIW, if you just want to write code, be comf…

... some people at Google would surely argue that my problem is that my ideas are crazy and bad ... To what extent are such disagreements purely technical (e.g. byte-oriented wire encodings vs. roughly-like-memory) and to what extent are they "political". By "political" I am talking about your claims about decentralisation and diversity, as if you are selling Sandstorm as the IBM-PC for the cloud millennium: a neutra…

I didn't actually propose massive decentralization while at Google, nor did I propose zero-copy encoding. So, no, I don't think I was proposing anything that threatened Google's business model.

Re: Cap’n Proto

#136

Post by kentonv »

Paul_S wrote: post #100

Would probably be a good idea to have a no-exceptions version.

You can compile Cap'n Proto with -fno-exceptions, and it does a bunch of things differently to make that work. Basically, invalid-input exceptions instead replace the invalid data with a reasonable default value and set a flag on the side that you can query to see if there was any invalid input. Assertion failure exceptions (where there is no way to recover) largely turn into fatal errors.

Re: Cap’n Proto

#137

Post by kentonv »

nemoNoboru wrote: post #134
bascule wrote: post #133

Earlier quoted context omitted.

Actually there was a Capnproto project for Ruby GSoC project this year! https://github.com/nemoNoboru/capnp-ruby https://rubygems.org/gems/capn_proto-rpc

Yep, that's my project. Please use it and contact me if somenthing doesn't work!

Hmm, should this be linked on the "other languages" page? I don't remember you telling me it was ready -- sorry if I missed something!

Re: Cap’n Proto

#138

Post by lobster_johnson »

bascule wrote: post #133
kentonv wrote: post #33

Earlier quoted context omitted.

I don't think anyone is currently working on Ruby bindings, but if you're interested, feel free to take it on! (Note that Sandstorm is focused on making Cap'n Proto work well for Sandstorm. We welcome contributions, but we generally don't have resources available ourselves to work on third-party feature requests unrelated to Sandstorm. That is, unless you want to pay us a bunch of money, in which case, feel free to c…

Actually there was a Capnproto project for Ruby GSoC project this year! https://github.com/nemoNoboru/capnp-ruby https://rubygems.org/gems/capn_proto-rpc

Awesome, thank you!

Re: Cap’n Proto

#139

Post by bchallenor »

lux wrote: post #115
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…

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

I recently evaluated the two and went with FlatBuffers, largely because its Java support appeared to be more mature.

The FlatBuffers encoding is based on vtables and is relatively straightforward (the runtime library is tiny). This also means it's inefficient for small messages, but in my testing its vtable deduplication worked great for my use case (~100k messages of the same type per memory-mapped file), in that the vtable overhead tends quickly to zero.

Cap'n Proto has a more complex encoding that is probably more efficient in terms of wire size, and particularly for small/standalone messages, but the runtime is larger as a result.

Re: Cap’n Proto

#140

Post by Matthias247 »

striking wrote: post #109
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 righ…

It's infinitely faster if you have control over the data layout in your application - which most likely means your are developing your application in C/C++, or maybe Rust. In the case of JS you don't have, so accessing and writing the data is slow (since you would need [de]deserialization there to write it in a byte array). In fact any serializations in JS are slower than JSON, since this is natively implemented in the JS VMs while others are not.
Post reply on HN