24 days of Rust – serde | Hacker News Reader

24 days of Rust – serde

siciarz.net

75 pointszsiciarz14 comments

It's been mentioned in the post, but it's a big deal, so for emphasis: serde is much nicer to use on nightly than stable, even though it will work on stable. This has been one of the biggest reasons people aren't on stable Rust. The tooling needed to get it working on stable with the same ergonomics as nightly is slated for Rust 1.15. It's not 100% for sure, but 99.99%.

This will also help crates like Diesel.

What is the tooling that's missing in stable?

There's also nom (https://github.com/Geal/nom) which is similar to Parsec and more designed for parsing text formats but used for binary formats too.

It's coming to 24 days of Rust as well :-)

Serde is short for "serialize/deserialize", nom is about parsing. Similar, but slightly different things.

Serde creator here. Steve's right, serde is fundamentally a generic protocol that implements serialization. I didn't use nom for serde_json (because it didn't exist at the time) but it's definitely possible to use nom and other parser generators to implement the serde protocol.

And it's only for nightly (see "feature") and it means it's can be used in reliable code. Talks about stabilizing of this feature are endless.

Serde code generation can be used on stable Rust, it just requires a bit of boilerplate code to setup: https://serde.rs/codegen-stable.html. Things will be much better once macros 1.1 gets stabilized.

codegen? lol, never. It would be enough reason to forget about Rust at all.

for silent downvoter: this line "Next create a file src/serde_types.in.rs to hold all the types for which we need code generation." sounds ridiculous for web projects with hundreds of entities, needed to be transferred as json objects trough API.

For what it's worth, you only need one file to be included. Any other files will be included and translated as necessary, so the only file that needs the .in extension is the root of the serde types.

Doesn't matter. Duplication of hundreds of structs is a nightmare when you want to change some fields.

Why do you think you need duplication of hundreds of structs?

There's no real difference with what serde_codegen does, and what the compiler does for expanding macros. It's just expanding to source rather than raw AST.

The idea would be that these types would be put into a library (or just another module) that's used by the rest of the app. There wouldn't be duplication of these structures. It's not ideal, which is why we are working on stabilizing the compiler features to do away from codegen.

Reply on news.ycombinator.com