In my year in review post, I wrote: To balance out the ongoing adoption of orphaned crates, I'm inclined to wind down maintenance of chrono and chrono-tz in the coming months. The API design for th...
rkyv is not like serde. There is no process of deserialization. The function rkyv::access(...) takes a &[u8], performs a consistency check, then casts the pointer it was passed to the desired type and returns Result<&T, Err>. I will say this again: “deserialization” in rkyv is a reference-to-reference conversion.
As you can imagine, it’s very fast, but the tradeoffs are massive. The serialized bytes must exactly match the memory layout of a struct (usually distinct from the type being serialized) called the “archived type” (which must be #[repr(C)] or #[repr(transparent)], and which is most commonly generated from the fields of the struct being serialized using a derive macro). More importantly, there is nowhere to stick deserialization code which could convert a Unix timestamp to a jiff::Timestamp.
You can’t really implement custom serialization schemes for third party types with it, at least not unless you want to define that #[repr(C)] struct yourself, and/or you’re okay with actually deserializing (in rkyv, the Deserialize trait accepts a reference to the archived type and returns an owned value of the serialized type, usually by effectively cloning it) and the performance cost that entails, and with how my codebase is currently architected, I’d have to redo it every time I used the value. rkyv support kind of has to be baked into a library from the get-go for it to be worthwhile.
You can custom serialize
(timestamp, tz)ortimestamp, offsetor(timestamp, tz, offset), no?Ironically, that was a part of a back-and-forth I had with burntsushi (jiff dev) right here on lemmy.
rkyv is not like serde. There is no process of deserialization. The function
rkyv::access(...)takes a&[u8], performs a consistency check, then casts the pointer it was passed to the desired type and returnsResult<&T, Err>. I will say this again: “deserialization” in rkyv is a reference-to-reference conversion.As you can imagine, it’s very fast, but the tradeoffs are massive. The serialized bytes must exactly match the memory layout of a struct (usually distinct from the type being serialized) called the “archived type” (which must be
#[repr(C)]or#[repr(transparent)], and which is most commonly generated from the fields of the struct being serialized using a derive macro). More importantly, there is nowhere to stick deserialization code which could convert a Unix timestamp to ajiff::Timestamp.You can’t really implement custom serialization schemes for third party types with it, at least not unless you want to define that
#[repr(C)]struct yourself, and/or you’re okay with actually deserializing (in rkyv, the Deserialize trait accepts a reference to the archived type and returns an owned value of the serialized type, usually by effectively cloning it) and the performance cost that entails, and with how my codebase is currently architected, I’d have to redo it every time I used the value. rkyv support kind of has to be baked into a library from the get-go for it to be worthwhile.