True zero-copy is not achievable with Protobuf, you need something like FlatBuffers for that. What is presented here is more like a zero-allocations.
Zero-copy protobuf and ConnectRPC for Rust
11–20 of 47 posts
Re: Zero-copy protobuf and ConnectRPC for Rust
#12Commonly used crates should be blessed and go into an extended stdlib.
No HTTP, Proto, or gRPC crate should ever find itself in the stdlib. Didn't we learn this with python? How many python http client libraries are in the dumping ground that is the python "batteries included" standard library? And yet people always reach for the one that is outside stdlib.
I would always go to the official docs page for the needs I have, and use their HTTP library (or any other). It removes decision making, having to ensure good quality practices from lesser known libraries, and risks of supply chain attacks (assuming the root stdlib of a language would have more attention to detail and security than any random 3rd-party library thrown into github by a small group of unpaid devs)
Only when it falls short on my needs, I would drop the stdlib and go in dearch of a good quality, reputable, and reliable 3rd-party lib (which is easier said than done).
Has worked me well with Go and Python. I would enjoy the same with Rust. Or at a minimum, a list of libraries officialy curated and directly pointed at by the lang docs.
Re: Zero-copy protobuf and ConnectRPC for Rust
#13Exciting!
I have been on a similar odyssey making a 'zero copy' Java library that supports protobuf, parquet, thrift (compact) and (schema'd) json. It does allocate a long[] and break out the structure for O(1) access but doesn't create a big clump of object wrappers and strings and things; internally it just references a big pool buffer or the original byte[].
The speed demons use tail calls on rust and c++ to eat protobuf https://blog.reverberate.org/2021/04/21/musttail-efficient-i... at 2+GB/sec. In java I'm super pleased to be getting 4 cycles per touched byte and 500MB/sec.
Currently looking at how to merge a fast footer parser like this into the Apache Parquet Java project.
Re: Zero-copy protobuf and ConnectRPC for Rust
#14bit-slicing the nth slice is 4-bit hex computing: microcontroller instrument assemblage
Re: Zero-copy protobuf and ConnectRPC for Rust
#15True zero-copy is not achievable with Protobuf, you need something like FlatBuffers for that. What is presented here is more like a zero-allocations.
I also find this misleading, and could be solved so easily by just explaining that of course varints need resolving and things will just happen lazily (presumably, I didn’t read the code) when they are requested to be read rather than eagerly.
Re: Zero-copy protobuf and ConnectRPC for Rust
#16True zero-copy is not achievable with Protobuf, you need something like FlatBuffers for that. What is presented here is more like a zero-allocations.
Is this still true? New versions of protobuf allow codegen of `std::string_view` rather than `const std::string&` (which forces a copy) of `string` and `repeated byte` fields.
Re: Zero-copy protobuf and ConnectRPC for Rust
#17About protocols in this vicinity, I've been noticing a missing piece in OSS around transport as well. In Python, you often need incompatible dependency sets in one app, and the usual choices are either ad-hoc subprocess RPC that gets messy over time or HTTP / containers that are overkill and make you change deployment strategy.
I ended up building a protocol for my own use around a very strict subprocess boundary for Python (initially at least, protocol is meant to be universal). It has explicit payload shape, timeout and error semantics. I already went a little too far beyond my usecase with deterministic canonicalization for some common pitfall data types (I think pickle users would understand, though). It still needs some documentation polish, but if anyone would actually use it, I can document it properly and publish it.
Re: Zero-copy protobuf and ConnectRPC for Rust
#18It's 2026 and I'm still defining my own messaging and wire protocols.
Plain C structs that fit in a UDP datagram that you can reinterpret_cast from is still best. You can still provide schemas and UUIDs for that, and dynamically transcode to JSON or whatever.
Re: Zero-copy protobuf and ConnectRPC for Rust
#19It's 2026 and I'm still defining my own messaging and wire protocols. Plain C structs that fit in a UDP datagram that you can reinterpret_cast from is still best. You can still provide schemas and UUIDs for that, and dynamically transcode to JSON or whatever.
If you decide to use UDP, do you ignore the transmission errors or write the handling layer on your own?
Re: Zero-copy protobuf and ConnectRPC for Rust
#20It's 2026 and I'm still defining my own messaging and wire protocols. Plain C structs that fit in a UDP datagram that you can reinterpret_cast from is still best. You can still provide schemas and UUIDs for that, and dynamically transcode to JSON or whatever.
If you decide to use UDP, do you ignore the transmission errors or write the handling layer on your own?
I handle it in different ways by topic.
For topics which are sending the state of something, a gap naturally self-recovers so long as you keep sending the state even if it doesn't change.
For message buses that need to be incremental, you need to have a separate snapshot system to recover state. That's usually pretty rare outside of things like order books (I work in low-latency trading).
For requests/response, I find it's better to tell the requester their request was not received rather than transparently re-send it, since by the time you re-send it it might be stale already. So what I do at the protocol level is just have ack logic, but no retransmit. Also it's datagram-oriented rather than byte-oriented, so overall much nicer guarantees than TCP (so long as all your messages fit in one UDP payload).