You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had a chat with @ludfjig about this yesterday and we concluded this probably sits in the path for 1.0, and might be a good target for a HIP. Before we move to an implementation, what I'd like to see written down is roughly:
What are the problems we have with flat buffers today?
How does serde solve those problems?
Which serde codecs are we considering for evaluation and why? (e.g. postcard, possibly others?)
It doesn't need to be expansive: just one paragraph per item would be fine imo. But I'd like us to get into the habit of documenting our motivation for changes within the repo, and the HIP process seems like the right way to go for that.
1. Problems. We use none of FlatBuffers' strengths. The host can't read guest memory in place safely, so it copies first, and both sides decode into owned types. Host and guest versions must match, so schema evolution doesn't help. We still pay for 6,100 lines of generated code, conversion layers, a verifier, a trace size estimator, and slow encoding.
2. How serde helps. The Rust types are the schema. Derives replace generated code and conversions, and decoding borrows strings from the buffer.
3. Codecs. postcard: no_std, stable 1.0 format, borrowed decoding. bincode is a weaker no_std fit. rkyv reads in place, which has the same double-read problem.
Swapping only the format made guest calls about 11–15% faster and encoding about 89% faster in short runs. postcard has no language-neutral schema, but only Rust encodes and decodes messages. C guests use the Rust C API, and other languages can do the same.
Activity
yoshuawuyts commentedon Aug 25, 2026
I had a chat with @ludfjig about this yesterday and we concluded this probably sits in the path for 1.0, and might be a good target for a HIP. Before we move to an implementation, what I'd like to see written down is roughly:
serdesolve those problems?serdecodecs are we considering for evaluation and why? (e.g.postcard, possibly others?)It doesn't need to be expansive: just one paragraph per item would be fine imo. But I'd like us to get into the habit of documenting our motivation for changes within the repo, and the HIP process seems like the right way to go for that.
ludfjig commentedon Oct 29, 2026
Answers from a local prototype. HIP to follow.
1. Problems. We use none of FlatBuffers' strengths. The host can't read guest memory in place safely, so it copies first, and both sides decode into owned types. Host and guest versions must match, so schema evolution doesn't help. We still pay for 6,100 lines of generated code, conversion layers, a verifier, a trace size estimator, and slow encoding.
2. How serde helps. The Rust types are the schema. Derives replace generated code and conversions, and decoding borrows strings from the buffer.
3. Codecs. postcard:
no_std, stable 1.0 format, borrowed decoding. bincode is a weakerno_stdfit. rkyv reads in place, which has the same double-read problem.Swapping only the format made guest calls about 11–15% faster and encoding about 89% faster in short runs. postcard has no language-neutral schema, but only Rust encodes and decodes messages. C guests use the Rust C API, and other languages can do the same.
ludfjig commentedon Oct 29, 2026
HIP: #1999