Is there an alternative to Serde for serialization/deserialization in Rust?
Minicbor for example, postcard
What is it you want to serialise/deserialise?
How about protobuf's crates.io: Rust Package Registry?
I deserialised a horrible proprietary binary format just by writing code to do it. No dependencies needed.
The value of serde is one party can define a format (De/Serializer, eg serde_json), while the other can define the structure (De/Serialize), with serde as (nearly) nothing but the interface between them.
Therefore, there's not too much value in an exact replacement of serde itself, as the problem statement effectively requires something fairly substantially similar for the solution, but also it then needs buy in from all the different formats, but maybe someone will find a way for those lines to cross at some point and makes a clearly better option.
But you probably don't need an exact replacement, you just either want to parse an existing format into your structures:
Or to implement such a format for yourself or others:
Note that you can often use the various serde_* packages without going through serde, eg serde_json::Value is just what JSON support looks like in nearly every other language.
1 Like
Bincode 2.0 has its own traits and derives that are optimized for its format. bincode - Rust
Miniserde is essentially the same thing but for JSON. miniserde - Rust
Then there's a true serde alternative, merde. merde - Rust
And if you want something totally different, there's rkyv. rkyv - Rust
2 Likes
Oh, the creativity when naming crates is sometimes astounding 
6 Likes
While it's currently indev, the crate treaty is targeted to be a strict upgrade to serde. Last I heard it was blocked on several side crates that the developer had to make for treaty to work, but that was a while ago.
(apologies, that was not meant to be a reply)
1 Like
When learning Solana, borsh is recommended for serializing and deserializing.
Since this thread ranks high in search results...
I think the "alternative to serde" means libraries that just like serde are not a specific serialization format, but aim at decomposing the data format and serialization it is being used to encode it.
I went through:
- miniserde - build in formats?
- merde - built in formats
- treaty - WIP, not sure, kindish?
- musli - kind of, multiple built in formats
and it looks like the answer ATM is: there really isn't any practical alternative to serde, as a universal serialization framework for Rust.
Which is a shame because serde is relatively old Rust project, it's API set in stone at this point, and there's probably a lot of things that could have been made differently/better given lessons from the current usage, ability to pick an API, etc. But the amount of effort required to crate and then maintain is big, so no surprise.
I really enjoyed musli, but it doesn't aim at being serialization interoperability crate, and just set of solutions for different uses integrated well together.
2 Likes
Having spent a bit of time in it's guts, I'm not aware of anything bleedingly obviously wrong with the current API that would make a serde replacement desirable. (If there was, there would probably be a serde 2 already)
If you try to implement a library equivalent to serde you pretty quickly find there's not actually much wiggle room in the design space here, at least while trying to minimize overhead.
Thinking about this a bit more, the most I can figure would be good to explore is providing different "standard" annotation attributes, making it easier to express more ambiguously structured formats like KDL which currently is nicest to use IMO via Knuffel - which implements it's own set of derive traits to give the very specific annotations that needs. Some way for the format to provide format specific annotations would be great, but I don't know how that would work, exactly.
3 Likes
Thanks. That's good to know.
Well, I've been googling around if there's any alternative due to a bug(?) affecting me immediately: human_readable flag does not get carried through · Issue #2704 · serde-rs/serde · GitHub , and was just wondering if I could derive a different set of trait or something for some niche serde alternative.
OTOH, I remember there were also some limitations for XML (not being able to represent some stuff), and around things like Option<Option<_>>, etc. but these are minor corner cases and a distant memory.
When looking through musli musli - Rust I've noticed:
We use GATs to provide easier to use abstractions. GATs were not available when serde was designed.
Also, when reading about musli's "modes" and thinking about that bug affecting me right now, it did occur to me that it would be great sometimes if serde could carry over more information about serialization format being used. E.g. would be nice if serialization code for my datatypes could detect that we're e.g. deserializing to CBOR and special case it because reasons. There are things like QR codes etc. where customizations like these are handy. Though maybe I could emulate using some thread-local context variable ...
I don't know. In the old days if we needed to serialise/deserialise something we would just write it for ourselves. I guess people are not into that idea much now a days.
There's a reason old software sucks so badly. "Back in an olden days" one had to roll about everything from scratch, including string handling. The stuff it took me months to implement 15 years ago in C, takes me a weekend now, with far better results. But my ambitions increased too.
1 Like
One of the problems that affects me most with serde is that it does not support comments/metadata for round-trip encoding: Add support for comments · Issue #2156 · serde-rs/serde This feature alone would be worth the price of admission for a viable alternative.
The precompiled binary for (This is no longer a concern. See @quinedot's response below.)serde_derive is an annoyance, but perhaps slightly better DX than slow builds.
2 Likes
Agreed. I bet we could add a couple more reasons and ambitious goals. We could have something less stable, more experimental and more ambitious, for these few times when this is needed.
Though ultimately it comes down to finding some crazy enough to do the work required. 
Having explored this a little bit, this is hard to do good enough you wouldn't constantly get bug reports for, as round-tripping also includes lots of other presentation details.
Currently the state of the art here AFAICT is you parse to a CST (concrete syntax tree, as opposed to an abstract one, including comments, whitespace, quoting styles etc...) then run a visitor to make whatever edits you want, including making a lot of decisions about representation.
You can do a bit better if you know a formatter is already being run, but you can't assume that in general. Ideally you're detecting an existing style or being provided it explicitly, bit I'm not aware of anything currently doing that.
I'm personally indifferent to preserving whitespace (unless it's essential to the specific format, as with YAML). But I understand that it isn't an easy problem, and didn't imply as much. None of this is to say it shouldn't be attempted, regardless. The use case speaks for itself.
1 Like