serde_derive now ships a precompiled binary. This made a lot of people angry. The crate maintainer finally locked the issue.
You must log in or register to comment.
To me, the fact that the issue was just outright dismissed by the maintainer without really answering any of the legitimate concerns raised (disregarding the unnecessary personal attacks in a few comments) is pretty concerning. And now the issue has been locked without a really good response.
Can someone explain why one would want to precompile procedural macros? Don’t they get compiled only once anyways, when compiling a dependent crate for the first time? So compile time should be not that relevant?
You’re correct, and that is part of the controversy.
One of the main reasons would be to try and hide what’s in it
If, for example, you wanted to add tracking code into the generated code, and knew people would stop using your product if they found out
Is there anything confirmed yet? Like what is inside this precompiled binary?
As far as I know, no one has yet been able to reproduce the binary with the source code, so I don’t think the contents of it are confirmed at all.
Tracking bullshit is very easy to find. Check for networking syscalls and done.
If someone does fork serde, can they at least make it so it actually follows semver?
Thanks, I hadn’t seen this elsewhere, glad to know about it.
