Serde 1.0.0 for Rust released
github.com
Serde 1.0.0 for Rust released
1–10 of 52 posts
Re: Serde 1.0.0 for Rust released
#2> Zero-copy deserialization
> […] The semantics of Rust guarantee that the input data outlives the period during which the output struct is in scope, meaning it is impossible to have dangling pointer errors as a result of losing the input data while the output struct still refers to it.
Re: Serde 1.0.0 for Rust released
#3It is a (de)serialization framework that can be quite easily implemented for various serialization formats like JSON, MessagePack, Yaml, toml, ...
It enables automatic and very performant (de)serialization of you data, into different formats.
Often with a simple:
` #[derive(Serialize, Deserialize)] struct Data { ... } `
Re: Serde 1.0.0 for Rust released
#4> Rust's "orphan rule" allows writing a trait impl only if either your crate defines the trait or defines one of the types the impl is for. That means if your code uses a type defined outside of your crate without a Serde impl, you resort to newtype wrappers or other obnoxious workarounds for serializing it.
I hadn't realized this. The justification is reasonable - preventing ambiguity when resolving traits - but it precludes one of the major use cases for traits/type classes: adapting a type from one library to an interface in another library without wrapper types.
Re: Serde 1.0.0 for Rust released
#5Re: Serde 1.0.0 for Rust released
#6Very nice: > Zero-copy deserialization > […] The semantics of Rust guarantee that the input data outlives the period during which the output struct is in scope, meaning it is impossible to have dangling pointer errors as a result of losing the input data while the output struct still refers to it.
To be fair, so does the semantics of every language with garbage collection -- keeping things alive while there are references to them is the bread and butter of GC.
EDIT: I do think it's impressive that Rust can manage this without the overhead of GC. But the sentence from the release notes immediately before 'killercup's quote was: This uniquely Rust-y feature would be impossible or recklessly unsafe in languages other than Rust which struck me as a bit over-hyped.
Re: Serde 1.0.0 for Rust released
#7Very nice: > Zero-copy deserialization > […] The semantics of Rust guarantee that the input data outlives the period during which the output struct is in scope, meaning it is impossible to have dangling pointer errors as a result of losing the input data while the output struct still refers to it.
>The semantics of Rust guarantee that the input data outlives the period during which the output struct is in scope To be fair, so does the semantics of every language with garbage collection -- keeping things alive while there are references to them is the bread and butter of GC. EDIT: I do think it's impressive that Rust can manage this without the overhead of GC. But the sentence from the release notes immediately…
Re: Serde 1.0.0 for Rust released
#8Very nice: > Zero-copy deserialization > […] The semantics of Rust guarantee that the input data outlives the period during which the output struct is in scope, meaning it is impossible to have dangling pointer errors as a result of losing the input data while the output struct still refers to it.
>The semantics of Rust guarantee that the input data outlives the period during which the output struct is in scope To be fair, so does the semantics of every language with garbage collection -- keeping things alive while there are references to them is the bread and butter of GC. EDIT: I do think it's impressive that Rust can manage this without the overhead of GC. But the sentence from the release notes immediately…
Re: Serde 1.0.0 for Rust released
#9 enum Syscall {
Open { pathname: Buffer, flags: u64, count: u64 },
Read { fd: u64, buf: Buffer, count: u64 },
...
}
I was very pleasantly surprised at being able to add a couple of dependencies, add #[derive(Serialize)] right above the struct, change two lines of my main driver program, and get an strace --json with useful output with no further effort. It's the sort of experience I expect from a higher-level language with dynamic types and runtime reflection, but available to me in a systems language.