Serde is great. I wish it did XML as well but that's a trickier proposition
The Serde Rust Framework
31–40 of 159 posts
Re: The Serde Rust Framework
#32Whilst not classical de/serialization I wrote serde_v8 ( https://github.com/denoland/serde_v8 ), an expressive and ~maximally efficient bijection between v8 & rust. It has powered Deno's op-layer since 1.9 ( https://deno.com/blog/v1.9#faster-calls-into-rust-with-serde... ) and has enabled significant improvements in opcall overhead (close to 100x) whilst also simplifying said op-layer.
Honestly using serde for language interop is one of my favorite things about serde, whether it's "classical de/serialization" or not. I've recently had the very-pleasant experience of writing some code that needs to pass geospatial data back and forth between Python and Rust, and found that the geojson crate, even though it's nominally for JSON, actually works with other serde-compatible things, including (something I found kind of miraculous) Python objects, using the pythonize crate, which can walk them with serde visitors. So as long as I can get my data into a roughly-geojson-shaped thing on the python side, I can consume it on the Rust side, without having to ever actually produce json.
Re: The Serde Rust Framework
#33I 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.
Isn’t it insane to change your types to accommodate this? You have to change all fields accesses, it behaves differently, you lose non-nullability…
Re: The Serde Rust Framework
#34Earlier quoted context omitted.
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.
Isn’t it insane to change your types to accommodate this? You have to change all fields accesses, it behaves differently, you lose non-nullability…
> Isn’t it insane to change your types to accommodate this?
Welcome to Go! This was a real pain for us at my last job, where we used go-swagger to generate REST API code. All the generated structs had pointers for _non-optional_ fields so it could also check that they were populated. Meanwhile, optional fields were not pointers because they could use the default value.
So then we ended up with lots of code doing checks for `is X nil` all over the place. Many of those wouldn't be needed in normal usage, since a nil value would be rejected by the validator earlier, but we also sometimes needed to make these structs by hand and pass them around.
All of this is necessary because of the lack of generics. With generics you can solve this with things like an `Option` type, like Rust does.
Re: The Serde Rust Framework
#35serde 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…
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-agnostic, it's really fast (not the absolute fastest, but fast enough for most situations), it's insanely customizable for even the weirdest use cases, it's absolutely everywhere, it incorporates proper error handling, and adding it to your own types is trivial.
Is there any actual reason something like serde couldn't exist in other languages? None that I know of, but it doesn't, 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't have to worry about this stuff.
Re: The Serde Rust Framework
#36Serde is great. I wish it did XML as well but that's a trickier proposition
Maybe this would work
Re: The Serde Rust Framework
#37Earlier quoted context omitted.
Fair enough. I have not found that to be true in C/C++, which is my main point of comparison. For very simple cases it's generally easier to write a few lines to a text file, maybe with some whitespace separators in the lines, than to use an "real" format. For JS and Python, JSON.stringify/parse and json.loads/dumps are a step up, but you still end up with an untyped mess with no schema validation, which makes them o…
Yea, but with serde, you don't get an untyped mess. You either get the type you expected or you get an error.
Same is true in any typed language.
Re: The Serde Rust Framework
#38I 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 just went from two years of professional Rust development to Go, and I’m right there with you. Thankfully we have some terrible C++ that looks to be a good candidate for a rewrite.
Re: The Serde Rust Framework
#39Earlier quoted context omitted.
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 possi…
Slow loris is I/O based, so it’s easy to abort. The rest will follow from that. Even if you piped your request stream into synchronous blocking io::Read adapter for use with Serde (which IMHO is pointless), the adapter will see an error due to its channel dropping, and bail out immediately.
Native busy-looping or deadlocked threads are tricky to kill safely, but that’s a general problem with threads in non-interpreted languages. Not specific to Serde, not related to Slow loris.
Re: The Serde Rust Framework
#40serde 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 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…
Studies have shown that more than 87% of complaints about rust compile time are because people are enabling serde everywhere and for everything.