// the find
anthropics/buffa
Rust implementation of protobuf with editions support, JSON serialization, and zero-copy views
buffa is a pure-Rust protobuf library built around editions as the core abstraction, rather than bolting editions support onto a proto2/proto3 design. It generates two types per message — an owned heap type and a zero-copy borrowed view — and passes the full binary/JSON/text conformance suite. The target audience is teams building proxies, gateways, or middleware in Rust that need unknown-field round-tripping and reflection without leaving the Rust ecosystem.
- The two-tier owned/view codegen is the right call for high-throughput decode paths. MyMessageView borrows directly from the wire buffer with no allocation; OwnedView<V> wraps a Bytes handle for crossing async boundaries. The MediaFrame benchmark at 70 GiB/s decode shows this isn't just theoretical.
- Linear-time serialization via SizeCache is a real correctness fix, not a micro-optimization. Prost's exponential blowup on deeply nested messages is a known landmine; having a size-caching pass built into the encode path means deeply-nested schemas don't silently degrade.
- Vtable reflection mode is clever: foo.reflect() borrows in place with no re-encode, so a CEL evaluator or transcoding gateway gets 475–719% faster field-read throughput than the bridge alternative. The read benchmark numbers are convincing.
- Unknown-field preservation by default is the correct behavior for anything used as middleware. Making it opt-out (rather than opt-in as in prost) means you don't silently drop data from a newer sender on a rolling deploy.
- The repo openly documents two spec-incorrect behaviors: closed-enum unknown values are silently dropped in packed-repeated view decodes and in map values. Both are supposed to be routed to unknown fields per the spec. If you're using proto2 with closed enums and evolving senders, you will lose data, quietly.
- Pre-1.0 with minor-version breaking changes is a hard sell for production infrastructure. A library that owns your wire format compatibility is a painful thing to pin at 0.7 and revisit every few months.
- JSON encode performance is essentially identical to prost (within ±11% across all message types), and JSON decode only wins because prost's JSON decoder is weak — not because buffa's is exceptional. If JSON is your hot path, this isn't a reason to switch from prost.
- The bridge reflection mode still re-encodes to construct a DynamicMessage (described as 'v1 cost'), so any code using reflect on generated types today incurs a 3–7x encode penalty. Vtable mode only exists for read access; the zero-copy reflection encode path isn't there yet.