As usual, nobody has said "capability" yet, which is unfortunate, because one of Capn's biggest strengths is that it embodies the object-capability model and is cap-safe as a result.<p>Edit: Why does this matter? Well, first, it matters because so little software is capability-safe. Capn's RPC subsystem is based directly upon E's CapTP protocol. (E is the classic capability-safe language.) As a result, the security guarantees afforded by cap-safe construction are <i>extended across the wire</i> to cover the entire distributed system. This security guarantee holds even if not every component of individual nodes is cap-safe, and that's how Sandstorm works.<p>Continuing on, there's also historical stuff going on. HN loves JSON; JSON is based on E's DataL mini-language for data serialization. HN loves ECMAScript; ES's technical committee is steered by ex-E language designers who have been porting features from E into ES.
This might be a contrarian view, maybe I'm misunderstanding it. To me, much of message passing is not performance critical, so it would be well served by JSON/YAML/XML for easy implementation/testing/debugging. If one needs performance, he can just send bytes over, which can be (de)serialised in a (couple) dozen SLOC. Sure, when you're talking about very complex structures, RPC, dynamic schemas etc., then you might opt for something like this, but let's be honest - that's quite a minority of current users, isn't it?<p>I never minded these frameworks, but then I wanted to write a few parsers for some file formats and they used Thrift/Flatbuffers to encode a few ints, which seemed like a major overkill. There was no RPC, no packet loss, no nothing.
Some time ago I wanted to use Cap'n Proto in the browser but then I found that the only existing implementation written in JavaScript hadn't been updated in two years and the author himself recommended against its use somewhere in a thread on Stackoverflow. I would love to use Cap'n Proto but for me a robust JS implementation is a sine qua non. Does anyone here happen to know if there's been any progress in this regard or have I missed something?
There is some strange geeky enjoyment from browsing all the serialization libraries out there. For my taste, I have centered on Cereal. When workind with C++ end to end, I have found it to be the easiest and fastest way to throw data around.
Woohoo! Lack of first class Windows support always held me back. Looking forward to playing with this and seeing hopefully more regular future updates.
Great stuff! Since this release comes after the release of GRPC and (slightly less related) Graph API and ships with a web server, how does it compare?
What always trips me up about capnproto is that it's billed as a serialization library, but what it is is an in-memory storage layout, and "serialization" is mostly just dumping memory into a file, right? (which is cool)<p>What confuses me is, then what are the costs of migrating to this system? Am I essentially dumping my programming language's object model for my capnproto implementation's? When can this be annoying? Or does it vary from implementation to implementation?<p>In a similar tangent - how similar is this to apache arrow, not because of the columnar analytics part, but could I expect to just dump a bunch of data in shared memory and read it from another process to eliminate IPC serialization/copy costs?
I think this[1] API among others should be renamed and "future" be used instead of "promise" to better reflect C++ naming conventions.<p>[1] <a href="https://github.com/sandstorm-io/capnproto/blob/247e7f568b1664cbcca1455243da06a7ab78c6a3/c%2B%2B/src/kj/async-io.h#L54" rel="nofollow">https://github.com/sandstorm-io/capnproto/blob/247e7f568b166...</a>
Windows support is great but why is this a showstopper? This is a common problem in many libraries and the common solution is to mark those platforms as unsupported until sometime steps up. Also platform support is a dynamic list - platforms are kept alive by presence of contributors/maintainers.
Ver nice and technically better than gRPC. However i better bet my company success on a standard that the big giant Google is betting on, and other companies are embracing. Also client side libraries for all langauges is important. Probably gRPC is probably better here too?
The name "Cap'n" was forever tainted for me, from my traumatic experience with "Cap'n Software Forth".<p><a href="http://www.art.net/~hopkins/Don/lang/forth.html" rel="nofollow">http://www.art.net/~hopkins/Don/lang/forth.html</a><p>"The first Forth system I used was Cap'n Software Forth, on the Apple ][, by John Draper. The first time I met John Draper was when Mike Grant brought him over to my house, because Mike's mother was fed up with Draper, and didn't want him staying over any longer. So Mike brought him over to stay at my house, instead. He had been attending some science fiction convention, was about to go to the Galopagos Islands, always insisted on doing back exercises with everyone, got very rude in an elevator when someone lit up a cigarette, and bragged he could smoke Mike's brother Greg under the table. In case you're ever at a party, and you have some pot that he wants to smoke and you just can't get rid of him, try filling up a bowl with some tobacco and offering it to him. It's a good idea to keep some "emergency tobacco" on your person at all times whenever attending raves in the bay area. My mom got fed up too, and ended up driving him all the way to the airport to get rid of him. On the way, he offered to sell us his extra can of peanuts, but my mom suggested that he might get hungry later, and that he had better hold onto them. What tact!"