Deser: Rethinking Rust Serialization

Many frustrations with Serde stem from its design choices: a single trait set that must serve both self-describing and type-driven formats, a fixed data model that loses format-specific information when buffering, and recursion on the call stack that risks stack overflows and prevents pausing deserialization. Concrete examples include serde_json’s arbitrary_precision using in-band maps that confuse internally tagged enums; flatten buffering keys as plain strings so integer-map keys fail when flattened; and deserialize_with functions that can’t be composed through wrappers like Option or Vec, forcing custom adapters and defaults. Those behaviors are not bugs so much as consequences of long-standing stability guarantees and trade-offs baked into Serde.

Deser flips the control flow: formats emit typed events to sinks and emitters held in a heap-based driver (an arena), avoiding recursion, enabling suspendable parsing, and preserving all format knowledge when buffering. It targets self-describing formats (JSON, YAML, TOML, CBOR, JSON5, XML, plist, etc.), offers an extensible data model with format-aware extension types, native non-buffering flatten, composable adapters, validators, Rust-expression attributes, and middleware “layers” for path tracking, limits and redaction. Trade-offs include larger binaries and mixed runtime performance, but Deser is now feature-complete enough to be a practical alternative for users willing to accept those costs and the deliberate exclusion of non-self-describing formats.