<story><title>The Serde Rust Framework</title><url>https://serde.rs/</url></story><parent_chain><item><author>UK-Al05</author><text>I think in most ecosystems it&amp;#x27;s easier to use a prebuilt serializer&amp;#x2F;deserializer than your own format.</text></item><item><author>roca</author><text>serde is one of the best things about Rust in practice.&lt;p&gt;It is more convenient to use serde to serialize&amp;#x2F;deserialize to some standard format like JSON or YAML than it is to write your own half-baked format and serialization&amp;#x2F;deserialization code --- even for the simplest tasks --- so you just stop doing the latter. This is a fundamental shift, and very good for your software.&lt;p&gt;&amp;quot;Convenience&amp;quot; here actually covers a lot of ground. The APIs are convenient. Boilerplate code is minimal (#[derive(Serialize)]). serde&amp;#x27;s attributes give you lots of control over the serialization&amp;#x2F;deserialization, while still being convenient to use. cargo makes importing serde into your project effortless. All of these are necessary to achieve that shift away from custom formats.&lt;p&gt;Before Rust I used to write a lot of one-off half-baked formats. Pernosco uses Rust and serde and it uses no half-baked formats. Everything&amp;#x27;s JSON, or YAML if it needs to be more human-editable, or bincode if it needs to be fast and compact and not human-readable or extensible.</text></item></parent_chain><comment><author>Jweb_Guru</author><text>Nah, not like it is in Rust.  For the vast majority of projects, serde makes parsing &amp;#x2F; serializing something they &lt;i&gt;don&amp;#x27;t even have to think about&lt;/i&gt;, without having to sacrifice type safety to get there.  Until you experience that in a large project with a lot of moving parts and developers, it&amp;#x27;s hard to appreciate just how many developer cycles you were wasting before on stuff that can be totally automated.  It&amp;#x27;s format-agnostic, it&amp;#x27;s really fast (not the absolute fastest, but fast enough for most situations), it&amp;#x27;s insanely customizable for even the weirdest use cases, it&amp;#x27;s absolutely everywhere, it incorporates proper error handling, and adding it to your own types is trivial.&lt;p&gt;Is there any actual reason something like serde couldn&amp;#x27;t exist in other languages?  None that I know of, but it &lt;i&gt;doesn&amp;#x27;t&lt;/i&gt;, at least not when you consider just how pervasive serde is in the ecosystem (almost every library that stores things you want to serialize will have it).  I really hope every language can standardize on something similar; it just makes development so much nicer and faster when you don&amp;#x27;t have to worry about this stuff.</text></comment>
<story><title>The Serde Rust Framework</title><url>https://serde.rs/</url></story><parent_chain><item><author>UK-Al05</author><text>I think in most ecosystems it&amp;#x27;s easier to use a prebuilt serializer&amp;#x2F;deserializer than your own format.</text></item><item><author>roca</author><text>serde is one of the best things about Rust in practice.&lt;p&gt;It is more convenient to use serde to serialize&amp;#x2F;deserialize to some standard format like JSON or YAML than it is to write your own half-baked format and serialization&amp;#x2F;deserialization code --- even for the simplest tasks --- so you just stop doing the latter. This is a fundamental shift, and very good for your software.&lt;p&gt;&amp;quot;Convenience&amp;quot; here actually covers a lot of ground. The APIs are convenient. Boilerplate code is minimal (#[derive(Serialize)]). serde&amp;#x27;s attributes give you lots of control over the serialization&amp;#x2F;deserialization, while still being convenient to use. cargo makes importing serde into your project effortless. All of these are necessary to achieve that shift away from custom formats.&lt;p&gt;Before Rust I used to write a lot of one-off half-baked formats. Pernosco uses Rust and serde and it uses no half-baked formats. Everything&amp;#x27;s JSON, or YAML if it needs to be more human-editable, or bincode if it needs to be fast and compact and not human-readable or extensible.</text></item></parent_chain><comment><author>roca</author><text>Fair enough. I have not found that to be true in C&amp;#x2F;C++, which is my main point of comparison. For very simple cases it&amp;#x27;s generally easier to write a few lines to a text file, maybe with some whitespace separators in the lines, than to use an &amp;quot;real&amp;quot; format.&lt;p&gt;For JS and Python, JSON.stringify&amp;#x2F;parse and json.loads&amp;#x2F;dumps are a step up, but you still end up with an untyped mess with no schema validation, which makes them only halfway solutions to me. I&amp;#x27;m a static typing guy at heart, sue me.</text></comment>