Read on Twitter
an angry rant on why i& #39;m *extremely* disturbed by recent Rust twitter discourse on dependencies [1/n]
a natural consequence of the current "dependencies are bad lol" meme is that library authors are going to start vendoring code from other libs in-tree (read: "copying and pasting code") in order to make their dependency counts smaller — i& #39;ve already seen this happen [2/n]
this (& #39;copying and pasting code& #39;) is *infinitely* worse than the worst-case scenario for libs having lots of http://crates.io"> http://crates.io deps. if a library has a security vulnerability, the authors can patch it, yank vulnerable versions, etc... [3/n]
...if library authors patch a vulnerability, and you depend on other crates that use the vulnerable library, and their dependency versions are compatible, cargo will probably pick up the patch automagically, and you won& #39;t be affected! [4/n]
ON THE OTHER HAND, if those library authors copied and pasted code from the vulnerable versions of a library, YOU ARE **FUCKED**. you are now relying on every crate author to be able to update code they copied and pasted forever ago and forgot about. [5/n]
(of course, this applies to bugs that aren& #39;t security vulnerabilities too) [6/n]
when you copy and paste code from another library, you are NOT actually decreasing your dependency count. what you& #39;re doing is creating a new
https://abs.twimg.com/emoji/v2/... draggable="false" alt="✨" title="Funken" aria-label="Emoji: Funken">special secret dependencyhttps://abs.twimg.com/emoji/v2/... draggable="false" alt="✨" title="Funken" aria-label="Emoji: Funken"> that cargo can& #39;t update for you anymore. [7/n]
odds are good that the Hidden Fun Dependency will now never be patched or updated ever again, and **nobody will know otherwise**. the Hidden Fun Dependency does not have a version number or cryptographic identifier. [8/n]
what i& #39;m saying is this: copy and paste is a STRICTLY WORSE package manager than cargo. it& #39;s also strictly worse than NPM, for that matter. but it has one advantage: people can& #39;t look at your lockfile or cratesio page and see how much code you& #39;ve copied and pasted [9/n]
library authors, for the most part, do NOT like copying and pasting code. we& #39;re going to have to vendor some code from dependencies in-tree in `tracing` soon, and i am *very* sad about it. [10/n]
it& #39;s for special-case reasons that are essentially "cargo doesn& #39;t have good tools for conditionally supporting no-std") [11/n]
With That Said, library authors DO know that people now care about how many dependencies a library has. and if the "lol deps r bad" meme forces libraries to compete based on how few deps they can *appear* to have on their cratesio pages, that& #39;s incredibly harmful. [12/n]
i say "appear" above because, in my opinion, copying and pasting code is **not** reducing the dependency count, it& #39;s just laundering it so it doesn& #39;t show up in cargo (and, in the process, making it Worse) [13/n]
also, this whole meme (and the related "lol delete all unsafe code, lol" meme) is *absolutely* a cargo cult. there are reasons that minimizing dependency counts can be worthwhile. but you have to understand *what you& #39;re doing*, and what a given dependency represents! [14/n]
oh, setting aside the whole security thing: people often use "binary bloat" as another reason that "lol deps r bad". but if the same identical code is copied and pasted into six libraries that you depend on...imagine what *that* does for your binary size. [15/n]
can the compiler tell that those functions are all the same? i don& #39;t think so. [16/n]
if code in several libraries calls into the same function from the same version of a dependency, how many versions of that function end up in my binary?
if each library copies the same function in-tree, *now** how many versions of that function end up in my binary? [17/n]
if each library copies the same function in-tree, *now** how many versions of that function end up in my binary? [17/n]
THE PRACTICAL UPSHOT OF ALL THIS is that selecting dependencies, like all things, involves Some Amount of Nuance. and the "lol deps r bad" meme is troubling because i rarely see that nuance acknowledged. [18/n]
oh, one more thing: if you think having more dependencies "makes your build slower"...it may actually make your build **faster**: #pipelined-compilation">https://blog.rust-lang.org/2019/09/26/Rust-1.38.0.html #pipelined-compilation">https://blog.rust-lang.org/2019/09/2... [19/n]
(provided, of course, that the alternative to having dependencies is "rewriting the same code in your crate") [20/n]
BONUS HOT TAKE: the anti-leftpad folks are going against the ancient and holy Unix creed of "do one thing well"
just in case this was not sufficiently clear: i am NOT complaining about the use-cases or threat models in which minimizing dependencies is legitimately important. what I& #39;m concerned about is that there seems to be a growing attitude that we should only use libs with 0 deps.
and the idea that dependency *counts* are a useful metric for anything. looking at individual dependencies critically and assessing what they& #39;re providing you is great. thinking that the total number of deps a crate has means anything useful is probably a mistake.
