@edescourtis So to make sure I understand your use case, you have a JSON-RPC server sending and receiving JSON, and you would ideally want
serde_rustlerto decode JSON into Erlang terms and vice versa?
No, I would simply like the structure to be essentially the same as for the JSON serialization. Meaning if I used the JSON serializer (serde_json) and then run Jason.decode/1 I would get the same value as getting an Erlang term from serde_rustler.
Regardless, can you provide some data structure examples (or preferably code snippets) to illustrate this shortcoming?
Rust struct Rgb { r: u8, g: u8, b: u8 } Elixir %Rgb{ r: u8, g: u8, b: u8 }
Rust struct Rgb { r: u8, g: u8, b: u8 } JSON {"r": u8, "g": u8, "b": u8}
Rust struct Millimeters(u8) Elixir {:Millimeters, u8}
Rust struct Millimeters(u8) JSON u8
The main issue here is when things get big and nested.
In my view it would be way better if it looked like:
Rust struct Rgb { r: u8, g: u8, b: u8 } Elixir %{r: u8, g: u8, b: u8}
Rust struct Millimeters(u8) Elixir u8
But this library only addresses performance issues for NIFs performing JSON (or any kind of) (de)serialization, so it’s still unclear to me what exactly is not working for you.
I was just explaining the common use case. A NIF avoids interprocess boundaries and network boundaries, Erlang terms avoid high serialization and deserialization overhead (this is where serde_rustler plays a role).
That said I am not saying that serde_rustler should not be able to annotate types the way it does (maybe there are use cases for that). I am simply saying that for most use cases I care about it creates problems significant enough I can’t use it at all.
