=== Does fRPC support protobuf backwards/forwards compatibility between message versions?
TL;DR - We don't currently, but we plan to.
We've built our own protobuf library called Polyglot, which encodes messages in an order based on their types rather than the number associated with the proto3 file. Because of this, we don't currently support backwards and forwards compatibility the way gRPC does.
=== Performance comparison with C++ arena allocations
TL;DR - We don't have specific benchmarks for this (yet).
C++ arena memory allocations are similar to Go's memory pools in the way they try to pre-allocate and reuse memory. fRPC is written in Go, but it doesn't currently use memory pools. Adding support for them is on the roadmap, though! that's a future optimisation that we expect will provide even further performance optimisations.
As far as C++ goes, though, the library is currently written in Go and we don't have a C++ version on the roadmap. That said, this is brand new and we're absolutely listening to determine if it makes sense to implement fRPC in other languages, such as C++ and Rust.
We wrote fRPC because we really liked the DevX and tooling around the proto3 syntax, but we needed the generated code to be significantly more performant than what gRPC provides.
We also needed the ability to extend the RPC framework with other messaging patterns (like pub/sub) and we needed to be able to reuse the underlying TCP connections as required.
There's no way to do this with gRPC (or any other RPC framework that I'm aware of), and so fRPC was born!
If you have any questions, feel free to drop them in the comments here! If I can't answer them directly, I'll pull in somebody who can.