I used this for a few years at a previous job and really liked it — it didn't get a ton of adoption by other people there, though, unfortunately. It had a bunch of cool ideas and seemed well implemented. I'm sad that it didn't work out as a commercial endeavor.

I like how they use capability-based security [0] and use Cap'n Proto protocol. This is another technology that is slow to get broad adoption, but has many things going for when compared to e.g. Protocol Buffers (Cap'n Proto is created by the primary author of Protobuf v2, Kenton Varda).

[0] https://sandstorm.io/how-it-works#capabilities

[1] https://capnproto.org

I recently evaluated different protocol libraries for inter-language IPC. The state of Cap'n Proto is sadly quite a bit worse than Protobuf. Many languages either don't have an implementation, or it hasn't been updated for several years.

But it's such a good system, I wish we could use it.

Some language implementations are under active development, like C++, Go and Rust. Others not so much. As language support comes, these are major ones. Let's hope they can drive the ecosystem forwards into more popular use.

I don't think it's going to happen with only a couple languages with good support. Messaging is fundamental enough that you don't want to swap libraries if not necessary, which means I won't choose it if the languages our products use are not well-supported. Just as a couple of examples:

- Node (& JS in general) have three implementations. One[1] mentions in the README that it's a hacky wrapper, the interface isn't final and the implementation is slow - for 9 years now. Another one[2] without support for RPC hasn't been updated in 4 years, and the last one[3] for 10 years.

- Lua[4] has been updated sporadically over the last couple of years, but the README mentions it ONLY works with LuaJIT v2.1, not with current Lua versions.

Currently it's hard to justify using it in a long-term project, considering how much broader the language implementations for Protobuf are. They also aren't perfect, but there is a lot more buy-in.

[1] https://github.com/capnproto/node-capnp

[2] https://github.com/capnp-js/plugin/

[3] https://github.com/jscheid/capnproto-js

[4] https://github.com/cloudflare/lua-capnproto

A tough road ahead, I agree. Currently there is other work going, by the Spritely Institute [0] non-profit. They are working on standard specifications fo the Object Capability Network (OCapN) [1] and Cap'n Proto may align with that. Spritely's object capabilities vision [2] looks very promising. Their open standards approach is very early stages still [3].

[0] https://spritely.institute

[1] https://github.com/ocapn/ocapn

[2] https://spritely.institute/static/papers/spritely-core.html

[3] https://ocapn.org