3 ms·

> 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 contra

> 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

Ygg2 2y ago
> - rusts type system is strong enough to build extremely powerful zerocopy serialization, but people don't explore that space because of serde 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.
j-pb 2y ago
Exactly! Serde is good enough that few people look for alternative ways of doing things (i.e. zerocopy), and the network effect incentivizes just integrating with it, to be compatible with all the other crates. At the same time (but orthogonal to the previous point) it serves as one of the first contact points and prime example of how to do metaprogramming in rust for new people (syn/quote and derive proc macros). This combination of being one of the first things you touch, it's age, and the fact that quote/syn IS a lot better API than what proc macros natively expose, has is in my opinion a lot of influence over (old and new) rust developer metaprogramming mindshare, and pushes the language down a specific garden path/design space. (What I'm trying to champion here is that this should be done more deliberately, much like jQuery eventually caused the cration of new querySelector web APIs.)

Ygg2 2y ago

> - rusts type system is strong enough to build extremely powerful zerocopy serialization, but people don't explore that space because of serde 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.

j-pb 2y ago

Exactly! Serde is good enough that few people look for alternative ways of doing things (i.e. zerocopy), and the network effect incentivizes just integrating with it, to be compatible with all the other crates. At the same time (but orthogonal to the previous point) it serves as one of the first contact points and prime example of how to do metaprogramming in rust for new people (syn/quote and derive proc macros). This combination of being one of the first things you touch, it's age, and the fact that quote/syn IS a lot better API than what proc macros natively expose, has is in my opinion a lot of influence over (old and new) rust developer metaprogramming mindshare, and pushes the language down a specific garden path/design space. (What I'm trying to champion here is that this should be done more deliberately, much like jQuery eventually caused the cration of new querySelector web APIs.)