TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Cap’n Proto

535 点作者 implmentor超过 8 年前

24 条评论

kentonv超过 8 年前
Hi all, Cap&#x27;n Proto author here. Thanks for the post.<p>Just wanted to note that although Cap&#x27;n Proto hasn&#x27;t had a blog post or official release in a while, development is active as part of the Sandstorm project (<a href="https:&#x2F;&#x2F;sandstorm.io" rel="nofollow">https:&#x2F;&#x2F;sandstorm.io</a>). Cap&#x27;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&#x27;n Proto socket (but compatibility layers on top of this allow apps to expose an HTTP server).<p>Unfortunately I&#x27;ve fallen behind on doing official releases, in part because an official release means I need to test against Windows, Mac, and other &quot;supported platforms&quot;, whereas Sandstorm only cares about Linux. Windows is especially problematic since MSVC&#x27;s C++11 support is spotty (or was last I tried), so there&#x27;s usually a lot of work to do to get it working.<p>As a result Sandstorm has been building against Cap&#x27;n Proto&#x27;s master branch so that we can make changes as needed for Sandstorm.<p>I&#x27;m hoping to get some time in the next few months to go back and do a new release.
评论 #12471622 未加载
评论 #12471595 未加载
评论 #12472117 未加载
评论 #12471793 未加载
评论 #12471837 未加载
评论 #12473036 未加载
评论 #12474109 未加载
评论 #12475564 未加载
评论 #12471619 未加载
评论 #12473666 未加载
评论 #12474349 未加载
评论 #12478590 未加载
评论 #12472607 未加载
评论 #12471735 未加载
评论 #12471660 未加载
评论 #12474350 未加载
Cyph0n超过 8 年前
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].<p>Anyways, it seems like a cool project, so I&#x27;ll be sure to follow its development closely.<p>[1]: <a href="http:&#x2F;&#x2F;vanilla-js.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;vanilla-js.com&#x2F;</a>
评论 #12471642 未加载
评论 #12471450 未加载
评论 #12472079 未加载
评论 #12471772 未加载
niftich超过 8 年前
I&#x27;ve always liked Cap&#x27;n Proto because it was (quite literally) the ideas behind Protobuf taken to an extreme, or, depending on your point-of-view, reduced to its most basic components: data structures already have to sit in memory looking a certain way, why can&#x27;t we just squirt that on the wire instead of some fancy bespoke type-length-value struct?<p>Of course, the hardest part is convincing everyone that it&#x27;s not <i>your bespoke</i> type-length-value struct, but that you have <i>good reasons</i> for what you&#x27;re doing. I think the humorous, not-so-self-serious presentation has worked in its favor (but that&#x27;s just a subjective opinion and I can&#x27;t back it up with data).
评论 #12471536 未加载
评论 #12471705 未加载
throwaway13337超过 8 年前
To get an overview of the area of binary interchange formats that are language agnostic, the author of Cap&#x27;n Proto does a good job in this:<p><a href="https:&#x2F;&#x2F;capnproto.org&#x2F;news&#x2F;2014-06-17-capnproto-flatbuffers-sbe.html" rel="nofollow">https:&#x2F;&#x2F;capnproto.org&#x2F;news&#x2F;2014-06-17-capnproto-flatbuffers-...</a><p>&quot;Protocol Buffers&quot; has been the go-to for a long time but there are more options now.<p>For uses where serialization&#x2F;deserialization CPU time is a concern, it seems to really a question of Cap&#x27;n Proto versus flatbuffers ( <a href="https:&#x2F;&#x2F;google.github.io&#x2F;flatbuffers&#x2F;" rel="nofollow">https:&#x2F;&#x2F;google.github.io&#x2F;flatbuffers&#x2F;</a> ).
评论 #12471597 未加载
评论 #12482250 未加载
评论 #12471971 未加载
评论 #12471736 未加载
评论 #12473782 未加载
评论 #12473860 未加载
Perceptes超过 8 年前
Big fan of what Sandstorm is doing, both with Sandstorm itself and this component. I <i>really</i> want to use this instead of gRPC, as it seems technically superior, but language bindings and adoption across language ecosystems are likely to be a big downside given that (as Kenton mentions in a comment elsewhere here) Sandstorm isn&#x27;t really interested in Cap&#x27;n Proto being widely adopted. All my new stuff is built in Rust, so the Sandstorm team&#x27;s interest in and use of Rust are a good fit for me. But when it comes to interoperability with other languages, this may end up being a concern compared to gRPC. In any case, I hope to see the Rust implementation eventually replace the C++ one as the official reference implementation.
评论 #12472059 未加载
venning超过 8 年前
Correct me if I&#x27;m wrong, but some of this sounds like <i>blitting</i>, except optimized for the in-memory structure and not the on-disk structure.<p>In 2008, Joel Spolsky wrote about 1990s-era Excel file formats and how they used this technique to deal with how slow computers were then [1]. Same technique, new problem set.<p>[1] <a href="http:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;items&#x2F;2008&#x2F;02&#x2F;19.html" rel="nofollow">http:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;items&#x2F;2008&#x2F;02&#x2F;19.html</a>
setori88超过 8 年前
Fractalide (<a href="http:&#x2F;&#x2F;githib.com&#x2F;fractalide&#x2F;fractalide" rel="nofollow">http:&#x2F;&#x2F;githib.com&#x2F;fractalide&#x2F;fractalide</a>) is an implementation of dataflow programming (specifically flow based programming). Component build hierarchies are coordinated via the Nix package manager. Capnproto contracts are weaved into each component just before build time. These contracts are the only way compenents talk to each other. Thanks Sandstorm.io for this great software.
评论 #12479026 未加载
megak1d超过 8 年前
I&#x27;ve always liked the look of this, saw it a while back but we are still using protobuf in our .NET environment simply due to the &quot;free&quot; schema generation using AOP&#x2F;attributes [ProtoContract]&#x2F;[ProtoMember] in Marc Gravell&#x27;s excellent protobuf-net (<a href="https:&#x2F;&#x2F;github.com&#x2F;mgravell&#x2F;protobuf-net" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mgravell&#x2F;protobuf-net</a>) project - I assume this would also be possible for cap&#x27;n proto.
zaptheimpaler超过 8 年前
Could this be used as an alternative to Apache Arrow[1]?<p>[1] <a href="https:&#x2F;&#x2F;arrow.apache.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;arrow.apache.org&#x2F;</a>
mrfusion超过 8 年前
I hate to ask but can anyone explain this like I&#x27;m from 2000?<p>I guess it&#x27;s a way to send data to your front end java script but not use json and this compresses it so it&#x27;s faster? How much better than using json is it?
评论 #12473388 未加载
评论 #12474156 未加载
wtbob超过 8 年前
&gt; 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!<p>Eh, I&#x27;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.<p>&gt; 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.<p><i>sob</i> There are a lot of things Intel has to account for, and frankly little-endian byte order isn&#x27;t the worst of them, but it&#x27;s pretty rotten. Writing &#x27;EFCDAB8967452301&#x27; for 0x0123456789ABCDEF is perverse in the extreme. Why? <i>Why?</i><p>As pragmatic design choices go, Cap&#x27;n Proto&#x27;s is a good one (although it violates the standard network byte order). Intel effectively won the CPU war, and we&#x27;ll never be free of the little-endian plague.<p>It&#x27;s all so depressing.
评论 #12471698 未加载
评论 #12471675 未加载
评论 #12472863 未加载
sandGorgon超过 8 年前
How do you pronounce the name? If libreoffice is bad.. This name is absolutely impossible.<p>Is it captain? Is it cap+n+proto?<p>A lot of collaboration is verbal - people sit around and talk about stuff. I don&#x27;t know if it is a fun take on an American word... But it is impossible to use in the rest of the world.<p>I really wish you would call it something else... Unless it is personal for you :(
评论 #12471933 未加载
评论 #12471920 未加载
评论 #12472146 未加载
评论 #12473578 未加载
joshuawarner32超过 8 年前
Here&#x27;s the discussion from a while ago: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=5482081" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=5482081</a>
chaotic-good超过 8 年前
I think that compression is a must for the serialization library. Protobuf uses almost twice less memory than Cap&#x27;n Proto. Using an external compression is not an option in some cases. E.g. consider building tcp-server that communicates with thousands of clients simultaneously. Each client connection will have its own LZ4 context that should be heap allocated. I believe it&#x27;s about 16KB per connection + buffers. This results in large memory consumption and a lot of random memory access and TLB misses.
评论 #12482350 未加载
flatline超过 8 年前
Interfaces! Inheritance! Looks promising. Protocol buffers are nice for their compact encoding and multi-language generator support but as a schema language they are really cumbersome. Composition is pretty much all you get, there are no longer required fields, you can&#x27;t even use enums as a key type in a map. I&#x27;m sure their use cases are not necessarily the same as mine but sometimes I miss just using plain old XML.
评论 #12471492 未加载
morecoffee超过 8 年前
&gt; capability-based RPC system.<p>This sounds like a cool idea, but so far I haven&#x27;t seen any good explanation of how it works, and why it will save me from rolling my own ACL system. For bragging about it in the very first sentence, there is surprisingly little detail about how it works.
评论 #12471706 未加载
mixmastamyk超过 8 年前
Apache thrift doesn&#x27;t seem to be mentioned, how does it compare?
评论 #12471954 未加载
Twonneilb22ll超过 8 年前
I&#x27;m happy to hear from you all in glad to see you&#x27;re doing all you can for updates Programs codes appreciate the hard work
Twonneilb22ll超过 8 年前
I&#x27;m happy to hear from you all in glad to see you&#x27;re doing all you can for updates Programs codes appreciate the hard work
Twonneilb22ll超过 8 年前
I&#x27;m happy to hear from you all in glad to see you&#x27;re doing all you can for updates
Paul_S超过 8 年前
Would probably be a good idea to have a no-exceptions version.
评论 #12474517 未加载
imaginenore超过 8 年前
Is it faster than MsgPack?
评论 #12471523 未加载
评论 #12471547 未加载
matmann2001超过 8 年前
.
TazeTSchnitzel超过 8 年前
Blender&#x27;s file format does something similar, it essentially saves a core dump to disk.
评论 #12474005 未加载