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

101–110 of 159 posts

Re: The Serde Rust Framework

#101

Post by Jweb_Guru »

pjmlp wrote: post #100
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…

That has been the same in Java and .NET world for 20 years now, just plug the desired serializer from the standard library and be done with it.

It absolutely does not provide the same guarantees, and I've covered why in several posts now. Do you believe that people who disagree with you have never used any language other than Rust before? Having to deal with data structure invariants getting violated due to reflection is a huge headache and makes the parsers way less useful than they would be otherwise.

Re: The Serde Rust Framework

#102

Post by dcow »

Jweb_Guru wrote: post #41
UK-Al05 wrote: post #19

Earlier quoted context omitted.

Most deserializers in typed languages allow you to deserialize straight into structs or typed objects... Serde just doesn't use reflection to do it.

APIs like GSON and Jackson have a lot more footguns, because (1) they attempt to (de)serialize types whether or not they were ever intended to be (de)serialized, (2) they are missing information about important constraints due to losing information at runtime (the excuse usually used here is that "they don't do validation" when in reality they are violating expectations of package modularity and encapsulation in a pr…

I’m pretty sure the non-null issue is fixable with a single config option, at least in GSON IIRC.

Re: The Serde Rust Framework

#103

Post by Jweb_Guru »

dcow wrote: post #102
Jweb_Guru wrote: post #41

Earlier quoted context omitted.

APIs like GSON and Jackson have a lot more footguns, because (1) they attempt to (de)serialize types whether or not they were ever intended to be (de)serialized, (2) they are missing information about important constraints due to losing information at runtime (the excuse usually used here is that "they don't do validation" when in reality they are violating expectations of package modularity and encapsulation in a pr…

I’m pretty sure the non-null issue is fixable with a single config option, at least in GSON IIRC.

I don't believe it's fixable at all if you're using someone's third-party library that wasn't designed for GSON (unless something has changed a lot since I last used it). The annotation has to be stuck on the original field, AFAIK. And similar stuff apply to other invariants on the type. I believe these kinds of issues are somewhat fundamental when you decide you're going to start (de)serializing structures that never thought about whether or how they'd like that to happen.

Re: The Serde Rust Framework

#104

Post by dcow »

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…

Swift also has native support. I am actually not a huge fan of the ergonomics of Go’s struct tags because of how cluttered they get in practice. It feels so unstructured like the rest of the language, but maybe that makes it perfect for Go.

Re: The Serde Rust Framework

#105

Post by option_greek »

Wulf_ wrote: post #94
option_greek wrote: post #89

Earlier quoted context omitted.

Please consider giving warp as choice for the web server.

Any particular reason?

Its more light weight and usually doesn't enforce any particular way of doing things. Regardless of warp support, I have most of the other things on your list integrated one by one (JWT/dashboards /react/diesel) but it was time consuming as I didn't have a quick start project template.

So I think the work you are doing is going to be valuable for the community. I guess giving an option between the three popular web frameworks (actix, warp, rocket) won't be so easy as you might have very different way of integrating the authentication etc with each. Probably one way to do this is to keep things more modular so that the authentication can be called independently (among other features).

Re: The Serde Rust Framework

#107

Post by dcow »

nevermind_29381 wrote: post #86
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 ...

Right, serde is one of the many features about Rust that people miss when writing Go. Simply a group of downtrodden programmers bonding over a shared experience the memory of which evoked when reminiscing on a grand cathedral. But alas the mere reminder of the existence of such a grand structure weighs on the heart of the plebeian. No need to rub it in sorry gogrammers’ faces that their language is a limp noodle in comparison. Thanks for reminding us (;

Re: The Serde Rust Framework

#108

Post by pjmlp »

Jweb_Guru wrote: post #101
pjmlp wrote: post #100

Earlier quoted context omitted.

That has been the same in Java and .NET world for 20 years now, just plug the desired serializer from the standard library and be done with it.

It absolutely does not provide the same guarantees, and I've covered why in several posts now. Do you believe that people who disagree with you have never used any language other than Rust before? Having to deal with data structure invariants getting violated due to reflection is a huge headache and makes the parsers way less useful than they would be otherwise.

Yes, because those same people seem to be unaware reflection is not the only way to use such APIs, revealing a superfical knowledge of how those ecosystems have been working for the last 25 years.

Re: The Serde Rust Framework

#109

Post by [deleted] »

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…

[deleted]

Re: The Serde Rust Framework

#110

Post by lmm »

lihaoyi wrote: post #87
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

Well "walk the object graph with a visitor" goes back at least to early (reflection-based) Java XML serializers; a generated-code version of the same thing is not a huge leap. I find it a frustratingly imperative way of approaching the problem: you can't think about what happens without thinking about control flow, because the visit can't be defunctionalized as a value. You may not want to physically reify the generic representation of the value - there would be a performance cost to that - but having it available to think about helps keep your code (and understanding) clear, in the same way that when doing a series of transformations of a large collection you probably want to be able to conceptualise "the collection in between step 1 and step 2" even if you don't want to actually instantiate that in memory at runtime.
Post reply on HN