Show HN: fcode is a binary rust-serde format that supports schema evolution(crates.io)
crates.io
Show HN: fcode is a binary rust-serde format that supports schema evolution
https://crates.io/crates/fcode
2 comments
I was generally OK with the speed of Prost, and making it faster was not the goal really. The goal was to make the generated code more Rust-friendly.
It is probably faster due to straightforward decoding, no tag switch. At the cost of not being able to reorder fields or remove in the middle.
With protobuf implementations, one always goes from schema to generated code, which means certain choices can not be handled without further markup:
- what to do with unknown enum values
- which fields become Option
- which string or bytes fields should be by-ref rather than by-value
- derive of other traits
I guess the alternative could have been to build all that into Prost, but that seemed unreasonable. I see this more as a replacement of bincode than as a replacement of Prost.
It is probably faster due to straightforward decoding, no tag switch. At the cost of not being able to reorder fields or remove in the middle.
With protobuf implementations, one always goes from schema to generated code, which means certain choices can not be handled without further markup:
- what to do with unknown enum values
- which fields become Option
- which string or bytes fields should be by-ref rather than by-value
- derive of other traits
I guess the alternative could have been to build all that into Prost, but that seemed unreasonable. I see this more as a replacement of bincode than as a replacement of Prost.
I can imagine that if you're able to outperform Prost using a similar wire format, there must also be a way to bring Prost up to par, or to design an alternative Protobuf implementation that's faster.
(Sorry if the above sounds a bit too negative; I'm just trying to figure out what the value is.)