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

21–30 of 159 posts

Re: The Serde Rust Framework

#21

Post by pornel »

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

Because of the way Rust's async works, you can put a timeout on anything (e.g. you don't need your http parser support timeouts, you can kill it at any await point). So it's only a matter of choosing timeout policy for your app. One person's DoS attack is another person's long polling API.

Anyway, it has nothing to do with Serde, which doesn't have a network component. For Serde you'd typically buffer the input first, or use external framing (like line-oriented JSON).

Re: The Serde Rust Framework

#22

Post by apendleton »

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…

If you want a field to be able to be not-set, you just need to specify that by making it an `Option` type. So like, if the field is a number, make it an `Option` -- that way you can distinguish between not-set (`None`) and set to zero (`Some(0)`).

Edit: whoops, misread which language it was you were frustrated with. Nevermind!

Re: The Serde Rust Framework

#24

Post by tylerhou »

apendleton wrote: post #22
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…

If you want a field to be able to be not-set, you just need to specify that by making it an `Option ` type. So like, if the field is a number, make it an `Option ` -- that way you can distinguish between not-set (`None`) and set to zero (`Some(0)`). Edit: whoops, misread which language it was you were frustrated with. Nevermind!

I know you’re giving helpful advice, but the author is talking (complaining) about Golang, which has no option typing (unless you want to use a pointer).

Re: The Serde Rust Framework

#25

Post by the_duke »

apendleton wrote: post #22
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…

If you want a field to be able to be not-set, you just need to specify that by making it an `Option ` type. So like, if the field is a number, make it an `Option ` -- that way you can distinguish between not-set (`None`) and set to zero (`Some(0)`). Edit: whoops, misread which language it was you were frustrated with. Nevermind!

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 generation), ...

Re: The Serde Rust Framework

#26

Post by yazaddaruvala »

Frankly Serde’s continued success has made it basically necessary for most Rust development. When the Bazzar organically builds and loves a mini-Cathedral it’s probably time to upgrade it to standard.

The increased complie times are the only real issue with Serde.

Especially if upgrading this crate into std would allow for a way to reduce the compile time “penalty” of very common formats like JSON, etc.

Re: The Serde Rust Framework

#27

Post by Taywee »

UK-Al05 wrote: post #19
pornel wrote: post #12

Earlier quoted context omitted.

The trick with Serde is that it decodes straight into a native Rust struct. You get most of validation for free (it also nicely takes advantage of Rust enums with data), and struct access is maximally fast. A generic JSON decoder would give you a dynamic structure that can contain anything, and then you'd have to pick it apart.

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

C++ isn't super easy about it, though. The best C++ json library (in my opinion), nlohmann's json, still requires you to define to_json and from_json for your types to use them. It's not too bad as a one-off, but when you have dozens of types, it gets really tedious compared to Serde, and managing std::variant with it is way more annoying than Serde with Rust enums.

Re: The Serde Rust Framework

#28

Post by the_duke »

pornel wrote: post #21
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

Because of the way Rust's async works, you can put a timeout on anything (e.g. you don't need your http parser support timeouts, you can kill it at any await point). So it's only a matter of choosing timeout policy for your app. One person's DoS attack is another person's long polling API. Anyway, it has nothing to do with Serde, which doesn't have a network component. For Serde you'd typically buffer the input first…

None of the current Rust async frameworks will prevent your synchronous code from going haywire.

Tokio or async-std timeouts only cancel futures. The dedicated spawn_blocking threadpools also do not support cancellation.

To prevent such cases you would have to spawn the work into a dedicated thread pool and then kill the thread on timeout.

Terminating threads is a very complicated topic though and not generally possible for compiled languages, especially without introducing memory unsafety.

The only real workaround is to have the synchronous code regularly check for cancellation via an atomic bool or similar, and terminate if required.

Re: The Serde Rust Framework

#29

Post by X6S1x6Okd1st »

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…

I've usually seen this handled by having everything be a pointer, the default value of the pointer is nil. You can also use the SQL values.
Post reply on HN