Well the article is about zero-copy deserialization in Rust. If you just slap #[derive(Deserialize)] on a bunch of 'static types and let it copy the strings, then you don't have this issue in Rust either.

Also, you'd be using Go, not Rust. That's fine, but not really relevant when you want to do JSON deserialization in Rust, is it?

What a wild conclusion to come to.

[–] thomask@lemmy.sdf.org 2 points 3 days ago (1 children)

It’s just a nod to the fact that I didn’t go into this project wanting to deal with zero-copy issues - it was decided for me by the library that I needed. Most of the time I do in fact slap Deserialize on a bunch of static types.

[–] TehPers@beehaw.org 2 points 2 days ago

This does seem like an issue with the library you're using. Your second solution, using RawValue, is likely what I would have gone with, bundled with a self-referential type (wrapping the Pin in another nicer-looking type though). This is assuming I want to pass around a 'static type with the partially-deserialized data. In fact, I've done something like this in the past to pass around raw log data next to that same data in a parsed format (where the parsed data borrows from the raw logs).

Alternatively, I'd have deferred the lifetime problem to someone else (library user for example) since the source data is probably provided at a higher level. This is how the libraries you're using do it from what I can tell. They make the LT the user's problem since the user will know what they want to do with the data.

[–] badmin@lemmy.today 1 points 3 days ago (1 children)

It's kind of funny how you didn't pick up on the connection between 3 and 4 😉

[–] thomask@lemmy.sdf.org 1 points 3 days ago

I did in the end, of course, but I encountered the two consequences separately and it wasn’t obvious at first.