4 ms·
> I’m just part of the peanut gallery Me too. As a Rust user and small-scale evangelist, I find this whole thing a bit interesting and also somewhat sad. At
by bacon_waffle 3y ago
> I’m just part of the peanut gallery
Me too. As a Rust user and small-scale evangelist, I find this whole thing a bit interesting and also somewhat sad. At least, it seems like increased awareness, and perhaps sandboxing, of proc macros are good outcomes that may result.
> how can you work something out when the maintainer can and has already just locked the issue and walked away?
That's not what happened here. dtolnay has not walked away, and the discussion is progressing. For instance, this pre-RFC [0].
> I don’t see a problem with the community forking
Serde, to the limited extent that I understand it, works because it is a single shared interface - multiple forks would be counter to the purpose of the project. That said, here we're talking about serde-derive specifically, so it's not quite a fork of the serde interface that we're talking about. But, I can understand why people might be upset that such an important a piece of the Rust ecosystem is such a flashpoint.
[0] https://internals.rust-lang.org/t/pre-rfc-sandboxed-deterministic-reproducible-efficient-wasm-compilation-of-proc-macros/19359 https://internals.rust-lang.org/t/pre-rfc-sandboxed-determin...
- evilduck 3y agoKudos for him for reverting the binary requirements but it was still weeks after the initial objections to foisting binaries onto users unannounced, with not much productive discussion in between that and that pre-RFC. It's not clear to me that anything would have happened without the mob attention, which sucks. But, I think the attention on proc macro performance and overall weaknesses in security with cargo could be net benefits, even if I don't personally care about a 9 second speedup in clean builds. I was also really dreading dealing with serde forks, selfishly.