Ok, but for it to be useful in a (Rust) program it has to be converted to a Rust type. At some point you'll have to do a conversion. Whether it's UTF-16 to String or string "false" to `bool`.
The reflection, code gen, etc. is the answer how you convert the values auto-magically.
I don't think anyone (j-pb included) is saying anything to the contrary.
Here's what you wrote:
>> rusts type system is strong enough to build extremely powerful zerocopy serialization
> Unclear what you mean, but other than syn and quote you don't have a way to reflect and do code gen, outside of build script. Which also use it.
But your response doesn't logically follow from the text you quoted (so I figured you weren't familiar with zero copy). This isn't j-pb saying that Rust's type system could be used to forgo proc-macros -- j-pb isn't saying anything about proc-macros in the text you quoted.
To be clear, these two points from j-pb's original comment are two separate, orthogonal issues:
> - rusts type system is strong enough to build extremely powerful zerocopy serialization, but people don't explore that space because of serde
> - macros and especially proc-macros in Rust are horrible, and are only feasible because of the syn crate
That's what I have a problem with. Pure Zero-copy parsers aren't explored because 99.9% of the time you have to escape and/or convert data to be useful.
Let's say we create a localization library that's zero-copy. Great, now whenever we call a field, since it's zero copy and might contain an escaped value, we need to invoke the escape function on it. So every call of field actually has an overhead of a method call, know what doesn't have that overhead? Converting it once and serving it constantly. But that's not zero-copy, as per the explanation given.
It's not due to serde, it's because people don't want or need a pure zero copy parser.
Zero-copy parsers, as you explained, make a lot of sense if you have a packet of data, do some mapping, evaluating and send it over the wire ASAP. That's not the same use case as storing data for longer time like settings, localization, serialization, etc.
> - macros and especially proc-macros in Rust are horrible, and are only feasible because of the syn crate
Macros by example, don't use syn crate, they are more like regex for syntax than anything.
Proc macros were always considered a kind of temporary feature that became a backbone of Rust. Pretty sure it was used a lot in some Servo components, plus it's kinda needed for many other things.
Additionally, syn isn't the only way to use in proc-macro. You're 100% free to roll your own, you just have to account for all the edge cases, all minor nits in language, etc. So you can write your own buggy version of syn, or you can use syn.