Part of the problem with cap'n'proto whenever I've approached it is that not only does it have an opinion on how to architect your server (fine, whatever) but in C++ it ends up shipping with its own very opinionated alternative to the STL ("KJ") and when I played with it some years ago it really ended up getting its fingers everywhere and was hard to work into an existing codebase.
The Rust version also comes with its own normative lifestyle assumptions; many of which make sense in the context of its zero-copy world but still make a lot of things hard to express, and the documentation was hard to parse.
I tend to reach for flatbuffers instead, for this reason alone.
Still I think someday I hope to have need and use for cap'n'proto; or at least finish one of several hobby projects I've forked off to try to use it over the years. There's some high quality engineering there.
Yes, it's true, the C++ implementation has become extremely opinionated.
I didn't initially intend for KJ to become as all-encompassing as it has. I guess I kept running into things that didn't work well about the standard library, so I'd make an alternative that worked well, but then other parts of the standard library would not play nicely with my alternative, so it snowballed a bit.
At the time the project started, C++11 -- which completely changed the language -- was brand new, and the standard library hadn't been updated to really work well with the new features.
The KJ Promise library in particular, which made asynchronous programming much nicer using the newly-introduced lambdas, predated any equivalent landing in the standard library by quite a bit. This is probably the most opinionated part of KJ, hardest to integrate with other systems. (Though KJ's even loop does actually have the ability to sit on top of other event loops, with some effort.)
And then I ended up with a complete ecosystem of libraries on top of Promises, like KJ HTTP.
With the Workers Runtime being built entirely in that ecosystem, it ends up making sense for me to keep improving that ecosystem, rather than try to make things work better across ecosystems... so here we are.
FWIW, one of the biggest obstacles to adoption of RPC components in our C++ codebase at work (not FB/Meta) is clean integration with our preexisting Folly + libevent scheduler. IMO, this has become a common theme across most C++ libraries that involve async IO. Rust has the same problem to a lesser extent. I think it's going to become a fundamental problem in all languages that don't have a strong opinion on, or built-in, async and schedulers.
Oh I understand completely how that would happen. I believe the first time I played with your work was not long after the C++11 transition, and so I could see why it happened.
This is why these days I just work in Rust :-) Less heterogenous of an environment (so far).
The Rust version also comes with its own normative lifestyle assumptions; many of which make sense in the context of its zero-copy world but still make a lot of things hard to express, and the documentation was hard to parse.
I tend to reach for flatbuffers instead, for this reason alone.
Still I think someday I hope to have need and use for cap'n'proto; or at least finish one of several hobby projects I've forked off to try to use it over the years. There's some high quality engineering there.