Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Serde Rust Framework

serde.rs

Post reply on HN
Print view View original

81–90 of 159 posts

Re: The Serde Rust Framework

#81

Post by the_duke »

eyelidlessness wrote: post #55
the_duke wrote: post #25

Earlier quoted context omitted.

You misunderstood, parent is complaining about Go, not about Rust. In Go you would have to use a pointer to represent Option , which makes code really awkward. Go serialization really has quite a few issues apart from default initialization. Configuration by somewhat weird struct tag strings which are only evaluated/validated at runtime, de/serialization is all done via reflection (unless you want to use code generat…

> In Go you would have to use a pointer to represent Option , which makes code really awkward. This sounded surprising to me, then I remembered Go doesn’t have generics. I imagine this won’t be as much of an issue when it does?

Emulating ADTs without language support/pattern matching is quite awkward. A prime example is std::optional in C++.

.map() et al only get you so far.

When extracting the value in Go you either have to return a pointer / error pair or abort. Both of which introduce awkward code patterns and potential for misuse.

Re: The Serde Rust Framework

#82

Post by namibj »

slaymaker1907 wrote: post #52
the_duke wrote: post #20

Earlier quoted context omitted.

The only downside is compile time bloat. Serde generates heaps and heaps of generic code. This all gets optimized away to be very efficient, but only once it reaches LLVM. Ever tried working on a crate with hundreds or thousands of de/serializable types? Compile times shoot through the roof really quickly, and serde is often the culprit. The maintainer of serde also created `miniserde` [1] to tackle this problem, whi…

Lack of orphan instances really aren't that bad of a problem in practice. If really necessary, the newtype pattern is very easy to do in Rust and has the benefit of never conflicting if the dependency adds a trait implementation. What is way more important is keeping your crate sizes manageable since IIRC Rust doesn't do any incremental/parallel compilation within a single crate. Compilation speed isn't just one numb…

You just do `incremental = true` and `codegen-units = 1024` (or how many shards you want, afaik per-crate), and it's perfectly incremental. Even thinLTO does incremental, but I suggest you use a modern linker instead of old GNU ld.

Re: The Serde Rust Framework

#83

Post by Jweb_Guru »

UK-Al05 wrote: post #66
Jweb_Guru wrote: post #35

Earlier quoted context omitted.

Nah, not like it is in Rust. For the vast majority of projects, serde makes parsing / serializing something they don't even have to think about , 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's hard to appreciate just how many developer cycles you were wasting before on stuff that can be totally automated. It's format-a…

I rarely have to think about deserialisation in c# or java either...

I wrote a lot of Java back in the day. I elaborated on why I disagree in the other comment. I do not know if the situation in C# is similar.

Re: The Serde Rust Framework

#85

Post by dwohnitmok »

spoiler wrote: post #63
vips7L wrote: post #37

Earlier quoted context omitted.

Same is true in any typed language.

I don't think that's true. Or at least we have different ideas about what's being discussed... Let's take JSON or YAML for example: Rust's closest siblings C and C++ are typed, and you get a pretty much untyped messes when working with serialisation or deserialisation. You have to manually inspect every node or write manual ”NodeType" to struct conversation. They allow unwrapping to primitives at best (eg via templat…

> In Haskell it's a bit more awkward, but you can kinda pull something similar off in terms of ergonomics. I've not worked with JSON in Haskell that much that I need to look for it, but I don't remember there being something as ergonomic as serde.

I think Haskell's most popular JSON library aeson is basically the same thing and probably a source of inspiration for serde.

  data MyCustomType = ... deriving (Generic, ToJSON, FromJSON)
or if you want more control you can use deriving-aeson

  -- I prefer snake case instead
  data MyCustomType = ...
    deriving Generic
    deriving (FromJSON, ToJSON)
    via CustomJSON '[FieldLabelModifier CamelToSnake]

Re: The Serde Rust Framework

#86

Post by nevermind_29381 »

the_gipsy wrote: post #13

I just came from rust to go and… what a disappointment. Missing fields default to some kind of default “zero value” - for any type, even full blown structs. You can’t tell the difference of a missing field or the field having the default value. So if a field has a validation of “must be greater than zero”, you can’t really give a proper error message. If user puts in “0” or omits the field, you always get a value of…

This is a thread about Serde, not how superior Rust and how shitty Go is. We've had more than enough from this ...

Re: The Serde Rust Framework

#87

Post by lihaoyi »

lmm wrote: post #79

Serde solves a lot of problems but using a dedicated macro for it feels like a real missed opportunity compared to using a generic macro for the part that needs a macro (treating structures generically), i.e. what frunk does, and then building serialization as just one of many possible use cases on top of that. Compare how this is done in the Scala ecosystem, where circe-generic is just one of many libraries that use…

On the other hand, Scala's uPickle works almost identically as how Serde does, originally for performance, but the final visitor-based architecture ended up being almost identical.

KotlinX serialization works basically the same way too; it definitely seems like a case of convergent evolution

Re: The Serde Rust Framework

#88

Post by brundolf »

Jweb_Guru wrote: post #35
UK-Al05 wrote: post #4

Earlier quoted context omitted.

I think in most ecosystems it's easier to use a prebuilt serializer/deserializer than your own format.

Nah, not like it is in Rust. For the vast majority of projects, serde makes parsing / serializing something they don't even have to think about , 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's hard to appreciate just how many developer cycles you were wasting before on stuff that can be totally automated. It's format-a…

Macros are definitely key. I wonder if ownership helps too? Circular references are always weird when serializing

Re: The Serde Rust Framework

#89

Post by option_greek »

_xyub wrote: post #80
xet7 wrote: post #10

Is there any Rust web framework that does not have problem with Slow-Loris ? https://github.com/SergioBenitez/Rocket/issues/1405

I thought I'd share this project in case anyone wanted to quickly evaluate rust for web https://github.com/wulf/create-rust-app Although there's a lot of work left to be done, I'd love to hear feedback, painpoints and ideas you have :) Hoping to have documentation up at create-rust-app.dev soon~

Please consider giving warp as choice for the web server.

Re: The Serde Rust Framework

#90

Post by thedracle »

roca wrote: post #2

serde is one of the best things about Rust in practice. It is more convenient to use serde to serialize/deserialize to some standard format like JSON or YAML than it is to write your own half-baked format and serialization/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. "Convenience" here actually covers a lot of…

The extendibility of it is impressive, as well as the list of formats supported by the community. The ability to output JSON for debugging next to tight-concise binary formats, is really appealing.

I've dealt with a number of C++ based serialization libraries, and they always have serious downsides to the point I often end up hand serializing structures with one-off half-baked formats just like you, which is error prone and laborious.

Post reply on HN