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

121–130 of 159 posts

Re: The Serde Rust Framework

#121

Post by chakkepolja »

dcow wrote: post #107
nevermind_29381 wrote: post #86

Earlier quoted context omitted.

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 c…

> No need to rub it in sorry gogrammers’ faces that their language is a limp noodle in comparison.

Say what you want about Go, but gophers get better jobs than you, meanwhile almost all rust jobs are shady crypto startups. Hard truth lol.

Re: The Serde Rust Framework

#122

Post by goldsteinq »

hawk_ wrote: post #120
apendleton wrote: post #22

Earlier quoted context omitted.

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!

when Optional is used in rust what's the memory layout like? is the absence tracked using a pointer which is null or a bitvector of optional fields?

Option would look like tagged union in memory, so one bit "tag", 8 bytes u64 and padding.

If type inside of Option has invalid values (like references which can't be null) one of these would be used for None, so Option is the same size as &T.

Re: The Serde Rust Framework

#123

Post by nicopappl »

Two things make serde great: (1) It's format agnostic (2) everyone in the community uses it.

My experience with other language ecosystem (I'm thinking Haskell or Scala) is that serialization/deserialization libraries are limited to one format, with incompatible APIs. Even if the libraries in those ecosystem provide the same kind of guarantees, it still doesn't compare to serde. Typically any framework or library (cats, play, scalaz, akka) will be either inflexible with format supports or require glue code (provided by the user of the library or a 3rd party) to even work with your pet codec library, which end up also limited to a specific storage format.

With serde, the assumption is just that things work, and it's fantastic. Example: I have my web server (written in rust) communicating messages to the frontend (in elm) with a websocket. For fun, I decided to test druid's wasm output when it came out (druid is a UI framework), see how feasible it would be to replace the frontend. And I could just pick up the type definitions from my rust server, add a websocket dependency that works on wasm and _it just worked_! I could then switch from json to msgpack and it worked the same.

The strength of rust is the community. There is a strong sense of collaboration and under the rich diversity of frameworks and high level libraries, there is a culture of modular and shared code and contributions that makes every thing that more flexible and reliable.

Re: The Serde Rust Framework

#124

Post by hawk_ »

goldsteinq wrote: post #122
hawk_ wrote: post #120

Earlier quoted context omitted.

when Optional is used in rust what's the memory layout like? is the absence tracked using a pointer which is null or a bitvector of optional fields?

Option would look like tagged union in memory, so one bit "tag", 8 bytes u64 and padding. If type inside of Option has invalid values (like references which can't be null) one of these would be used for None, so Option is the same size as &T.

thanks and is the padding for aligned access (wasted space) or just full byte (poor performance on non x86/64 like architecture)? because that's the interesting part as to what's the tradeoff chosen and whether a dev can choose a different one. Any doc references are appreciated.

Re: The Serde Rust Framework

#125

Post by sli »

spoiler wrote: post #112
rudedogg wrote: post #77

Earlier quoted context omitted.

> 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…

Ah, I don't use Apple devices, so I've never been able to play with Swift(1). So I didn't know Swift had it too; thank you for pointing it out! (1): which is a shame, I remember when it came out that it seemed like a nice language

Swift is available for Windows 10 and a few Linux distros (Ubuntu, Cent, and Amazon Linux 2) according to their download page.[0] If you're still interested, go give it a shot.

[0]: https://swift.org/download/

Re: The Serde Rust Framework

#126

Post by UK-Al05 »

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.

Why would reflection break invariants? Most deserializers can pass through data into the constructor via reflection as well, where you can protect against invalid objects.

Re: The Serde Rust Framework

#127

Post by CraigJPerry »

Fiahil wrote: post #118
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…

It's a tradeoff. Switch to Python and watch your serialization code become at least 10x slower at runtime.

10x slower seems unlikely - if in python you’re using the same rust serde library for your json parsing or whatever, E.g. you “poetry add orjson” to pull rusts serde lib into your python project, then the actual serde operations themselves will be native rust speed.

Re: The Serde Rust Framework

#128

Post by andrewaylett »

spoiler wrote: post #115
pjmlp wrote: post #108

Earlier quoted context omitted.

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.

How is it implemented in Java or C# if not via runtime reflection? I've always assumed that's the way its done...

I'd always recommend folk use constructor-based deserialisation, rather than getting the deserialiser to create empty objects and poke at fields.

That's still (at least naively) using reflection, but it's a lot safer.

In practice, using reflection for every object being deserialised is far too slow and Jackson at least generates code at runtime rather than repeatedly reflecting. That's magic, but it's nice magic because it's not breaking the language: one can see that it's possible to implement it in pure Java.

Re: The Serde Rust Framework

#129

Post by pjmlp »

spoiler wrote: post #115
pjmlp wrote: post #108

Earlier quoted context omitted.

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.

How is it implemented in Java or C# if not via runtime reflection? I've always assumed that's the way its done...

You can use stuff like VS T4 templates or compiler plugins via annotation processors.

So at compile time, just like serde works, you create your type safe serializer.

Re: The Serde Rust Framework

#130

Post by wongarsu »

praveen9920 wrote: post #70

I’m surprised to see that they don’t support protobuf yet which seem to be gaining. But otherwise seems like a good framework

Yes, that would be really nice. Protobuf doesn't really fit the model of serde though because of how closely coupled it is to its schema files. Still, there's two good implementations with the prost [0] and the protobuf [1] crates to choose from.

0: https://crates.io/crates/prost

1: https://crates.io/crates/protobuf

Post reply on HN