I’m surprised to see that they don’t support protobuf yet which seem to be gaining. But otherwise seems like a good framework
I believe that is implemented by a separate crate that simply implements ‘(De)Serialiazable’
The Serde Rust Framework
71–80 of 159 posts
Re: The Serde Rust Framework
#72Earlier 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…
Most typed languages it's like this
var account = JsonConvert.DeserializeObject(string/stream)
That's it. No inspection or looping through trees. You can often get it to create objects via constructor for validation.
It's been like this for 15 years...
Re: The Serde Rust Framework
#73Earlier 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…
Maybe we are having different ideas about what is being discussed, but in Java and C# (arguably the most mainstream languages) you have the same experience supported natively via annotations and attributes.
Re: The Serde Rust Framework
#74Earlier 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…
I don't think so. Speaking as a Rust dev, if you want to do anything slightly different from how things currently work, you need to change the types, which can be a major hassle.
Re: The Serde Rust Framework
#75Earlier quoted context omitted.
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…
Most typed languages it's like this var account = JsonConvert.DeserializeObject (string/stream) That's it. No inspection or looping through trees. You can often get it to create objects via constructor for validation. It's been like this for 15 years...
[deleted]
Re: The Serde Rust Framework
#76Earlier 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…
If you’re blocking on IO that’s you’re cancellation signal. You can of course close the pipe you’re reading from which surfaces an error in your synchronous thread.
Re: The Serde Rust Framework
#77Earlier 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…
> Of the "mainstream" languages Go is pretty much the only one that has as good ergonomics as Rust in that it supports it pretty much natively (via struct tags)
Swift does this too, using the Codable Protocol. The compiler generates the protocol conformance code for you, if you say a type is `Codable`, and the properties the type contains are all Codable types (Int, Float, String, URL, etc. conform to it), you don't have to do anything.
https://developer.apple.com/documentation/foundation/archive...
Re: The Serde Rust Framework
#78Earlier 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…
> Is there any actual reason something like serde couldn't exist in other languages?
C# standard library has DataContractSerializer for decades. That thing reads/write text XML by default, but with minor tweaks can do binary XML or JSON.
I like their binary XML format the most. Very fast because doesn’t waste time printing or parsing numbers or Base64 bytes. Also, pre-shared XML dictionary, and session-accumulating dynamic dictionary, makes the serialized representation very compact, sometimes an order of magnitude better than text/xml.
Re: The Serde Rust Framework
#79Serde 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 shapeless to represent datatypes as generic records (and then serialization proceeds from there), and the same representation code is also used by e.g. doobie (a sort of lightweight ORM) to transform records to and from database rows.
(Or, better still, building generic representation of structs as records into the language/compiler, where the whole ecosystem can depend on it and we don't have to bloat compile times generating it with a macro).
Re: The Serde Rust Framework
#80Is 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~