This kind of articles confirms for me that one of the largest quality-of-life improvement of Rust over C++ is being able to do some decent amount of reflection and code-generation in-language with annotations. Thankfully it’s happening after decades of C++ people screaming at the mere idea of reflection in comp.lang.c++ and various official forums.
Overall nice article. This is small but one thing I found a bit distracting was use of package which I don’t think is a valid Rust keyword, perhaps you meant mod?
Another question: have you considered just checking-in the generated code rather than forcing clients of the library to have to run the proc-macros as part of their build process? The JSON files should not change very often I’d imagine?
Thank you for taking the time to read and comment. Much appreciated! Package is now mod(ule). Not quite sure what I was thinking there :)
It does changes enough to be annoying! Tagged fields enable the protocol to change without incrementing the version, and small bug fixes (e.g., spelling of fields). We’re also implementing the broker, so we tend to pick up changes more frequently, than (say) a client might want pick a version and stick with it.
Also once generated it won’t rebuild unless the underlying JSON changes - I do a “cargo::rerun-if-changed={json file}” during the build.rs. On my todo list is to map the JSON comments into rust doc comments, and then can look at check-in of the generated code.
This kind of articles confirms for me that one of the largest quality-of-life improvement of Rust over C++ is being able to do some decent amount of reflection and code-generation in-language with annotations. Thankfully it’s happening after decades of C++ people screaming at the mere idea of reflection in comp.lang.c++ and various official forums.
Overall nice article. This is small but one thing I found a bit distracting was use of
packagewhich I don’t think is a valid Rust keyword, perhaps you meantmod?Another question: have you considered just checking-in the generated code rather than forcing clients of the library to have to run the proc-macros as part of their build process? The JSON files should not change very often I’d imagine?
Thank you for taking the time to read and comment. Much appreciated! Package is now mod(ule). Not quite sure what I was thinking there :)
It does changes enough to be annoying! Tagged fields enable the protocol to change without incrementing the version, and small bug fixes (e.g., spelling of fields). We’re also implementing the broker, so we tend to pick up changes more frequently, than (say) a client might want pick a version and stick with it.
Also once generated it won’t rebuild unless the underlying JSON changes - I do a “cargo::rerun-if-changed={json file}” during the build.rs. On my todo list is to map the JSON comments into rust doc comments, and then can look at check-in of the generated code.