Hacker News new | past | comments | ask | show | jobs | submit login
24 days of Rust – serde (siciarz.net)
75 points by zsiciarz on Dec 8, 2016 | hide | past | favorite | 14 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.


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.


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


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.


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.


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




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: