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.

sigh

I used chrono because it allowed storing a statically known timezone with 0 additional runtime bytes and had rkyv support. Both very important features for my application (rkyv database containing millions of timestamps).

I have yet to find a replacement library that supports either of these features.

i’m not sure there’s any metric by which the soviet union could be called a success but go off king