Live data from Hacker News

Serde 1.0.0 for Rust released

github.com

1–10 of 52 posts

Re: Serde 1.0.0 for Rust released

#2
Very 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.

Re: Serde 1.0.0 for Rust released

#3
Serde really is one of the gems of the Rust ecosystem.

It 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
As an aside:

> 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

#5
Serde is the kind of magic that we all hoped a type system like Rust's would cause. The transcode and zero-copy stuff is so neat. Doing stuff like this under the hood and "for free" is a nightmare in other languages.

Re: Serde 1.0.0 for Rust released

#6

Very 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 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

#7
post #6

Very 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…

But Rust doesn't have garbage collection, which is why this is interesting in the first place. :P And being able to statically rule out any spurious copies/alloctions (the "zero-copy" bit) while guaranteeing safe pointer usage (especially for string data) is something that Rust is very good at.

Re: Serde 1.0.0 for Rust released

#8
post #6

Very 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…

Rust does the inverse- it doesn't extend the lifetime of the input data, it restricts the lifetime of the output struct.

Re: Serde 1.0.0 for Rust released

#9
I'm working on an strace implementation in Rust, with an enum (tagged union) for system calls:

  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.
Post reply on HN