Show HN: fcode is a binary rust-serde format that supports schema evolution (opens in new tab)

(crates.io)

14 pointstijsvd4y ago2 comments

2 comments

The README mentions it's "significantly faster than protobufs (Prost implementation)", but also mentions that the wire format is pretty similar. This makes me wonder: why would you want to use this over Protobuf? Protobuf has a larger ecosystem, and support for many other programming languages.

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.)

tijsvdOP4y ago

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.

j / k navigate · click thread line to collapse