So, serde seems to be downloading and running a binary on the system without informing the user and without any user consent. Does anyone have any background information on why this is, and how this is supposed to be a good idea?
dtolnay seems like a smart guy, so I assume there is a reason for this, but it doesn’t feel ok at all.
You must log in or register to comment.
It seems it was done to marginally improve serde_derive build times? And just on x86_64-unknown-linux-gnu?
It feels a pretty weird course of action, even if I can understand his point of view his official stance of “My way or the highway” seems a bit stronger than needed, especially considering the amount of problems - both moral and pratical - this modification arises.
I don’t know. If he really feel so strongly about it the only real option would be an hard fork, but a project of that magnitudo and so integrated in the ecosystem is really not easy to both manage or substitute.
Overall it kind of leave a sour taste, even if - I repeat - I understand it is his time and his decision to make.
It seems it was done to marginally improve serde_derive build times? And just on x86_64-unknown-linux-gnu?
Indeed. If you use nix instead of compiling in 8 seconds it fails to compile almost instantly.
The same feature is planned for Windows and MacOS. https://github.com/serde-rs/serde/pull/2523#pullrequestreview-1583726636
The build time improvements are so marginal in a production environment where hundreds of crates are built. This decision demonstrates a strange inversion of priorities and smells of premature optimization to me. It’s so odd to see even further optimizations building on this “serde helper process” pattern.
I hate that I’m linking to Reddit, but I’m just reminded of this.
Some of us knew where all the obsession with dependencies’ compile times will lead, and triggered the alarm sirens, if half-jerkingly, years ago.
Compile times, and more specifically, dependencies compile times, is and has always been the most overblown problem in Rust. We would have some sort of sccache public repositories or something similar by now if it was that big of a problem.
And yes, I’m aware
proc-macrocrates in particular present unique challenges in that field. But that shouldn’t change the general stance towards the supposed “problem”. And it should certainly not trigger such an obsession that would lead to such a horrible “solution” like thisserdeone.I hate that I’m linking to Reddit, but I’m just reminded of this.
OT, but remember you can always use an archived link instead of a live one.
I get why the binary is there, but there really should be a simple way to force compilation instead of downloading a precompiled binary.
Serde is incredible though, so it can get away with basically anything it wants.
Serde is incredible though
Sure. Fork of it can be incredible too. In fact the only difference can be traditional approach to building the derive macro. All it takes is for people to switch.
I saw some other crate doing something similar but using wasm, the idea is to sandbox the binary used as a proc macro. So that seems a bit better. Can’t see to find it any more.
EDIT: Found it https://lib.rs/crates/watt
Fun fact: the guy who wrote
wattis the same guy who wroteserde.Made by the same guy
serdeis maintained by dtolnay, he is not the original author.I thought he was a genious inventing so many useful tools. Does he maintain other projects he didn’t create?
Not sure, possibly. You still need to be pretty smart maintaining and extending all those tools.
The second comment explains a lot. There is a build script that generated the binary, which they are using to reduce the overall build time. They mention this resulting from a limitation on cargo and this being a workaround
It seems like you could build it all from scratch if needed with a bit of effort
Wow, thank you for making me aware
