If I had chosen to write this code in Go I never would have had to think about any of this and I expect it would have been fine.
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?
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.
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.
Well the article is about zero-copy deserialization in Rust. If you just slap
#[derive(Deserialize)]on a bunch of'statictypes 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.
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.
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 thePinin another nicer-looking type though). This is assuming I want to pass around a'statictype 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.