Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serde support #74

Closed
hansihe opened this issue Jan 19, 2017 · 6 comments
Closed

Serde support #74

hansihe opened this issue Jan 19, 2017 · 6 comments
Milestone

Comments

@hansihe
Copy link
Member

hansihe commented Jan 19, 2017

Working with these can absolutely be done right now, but doing so is a bit of a chore.

  • Elixir structs
  • Keyword lists
@hansihe hansihe added this to the 1.0 milestone Jan 19, 2017
@cgregfreeman
Copy link

This would be fantastic.

I was able to get Serde to work very quickly with Rustler. However, this involves encoding/decoding JSON to pass it into the NIF. I suppose other formats like BSON or CBOR could be used, but they all add some overhead.

Serde looks to use a Derive macro for generating the boilerplate required so that any rust structs can have the serialize/deserialize methods automatically generated.

Would have such a macro in Rustler be the right tool for the job?

@scrogson
Copy link
Member

@cgregfreeman using JSON back and forth is unnecessary overhead.

This is issue is geared towards being able to pass in maps or keyword lists (a list of 2-element tuples where the keys are atoms) and be able to extract out items from those data structures more easily.

@hansihe
Copy link
Member Author

hansihe commented May 10, 2017

While it is true that Serde wasn't what I thought of when I opened this issue, @cgregfreeman does have a valid point.

Serde has established a very well understood and common interface for serializing and deserializing data from a wide range of formats. While it is true that going through a binary format would be unnecessary overhead, it would be possible to implement a Serde serializer and deserializer for working directly with Erlang terms.

I recall looking at this earlier in the project as a potential alternative to having our custom interface for working with Erlang terms. The reason why I chose to go with our own interface was that it was not possible to work with lifetimes in the way we needed through Serde. This would force us to copy a lot more data than strictly necessary, and we would therefore impose a fairly large non-negotiable performance overhead on the user.

It would be very nice to have a Serde interface in addition to the current interface. While it would be less efficient for some tasks, it would make a lot of things much easier for the user.

@hansihe hansihe changed the title APIs for working with more complex data structures Serde support Mar 8, 2019
@sunny-g
Copy link
Contributor

sunny-g commented Jun 9, 2019

@cgregfreeman Wrote a library called serde_rustler that should help with this :)

@turion
Copy link
Contributor

turion commented Feb 10, 2022

So is the idea to incorporate serde_rustler into the rusterlium codebase in the long run? Or depend on it for code generation?

@evnu
Copy link
Member

evnu commented Nov 11, 2022

Closing in favor of #200.

@evnu evnu closed this as completed Nov 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants