Rustaceans at the border
In my eyes, the problem isn&#x27;t precisely whether some components are <i>downloaded</i> separately. What I find problematic is the idea of giving up responsibility by dependending on separately developed components. Components written with more than just one particular project in mind are tough to change. Integrating them into a particular project often requires workarounds and some imperfect abstractions to make things fit, and there tends to be a proliferation of blind spots about &quot;global optimization potential&quot;.<p>Not to drag on Rust, but I can see a &quot;global optimization&quot; problem when I try to cargo build a moderate Rust project and have to download hundreds of transitive dependencies, and have a good chance of ending up not building a thing (for reasons that probably include my own incompetence, but still).<p>There are of course tons of C projects that have similar problems in a way - the number of dependencies might be lower but I have to hunt them manually. But well-engineered projects are at most a handful of clearly identifiable dependencies, and everything will generally build without fuss. This is how it is with the Linux kernel today. The main dependency of the Linux kernel is gcc, and as far as I perceive, communication between Linux and gcc projects is alive.<p>I think there is a lesson that can be learned in particular from C development: There is value in growing a system vs mainly integrating existing stuff (junk or not). The larger a project gets, the more sense it makes for it to bring its own tools and implementations so it can continue to build and be maintained as a whole without a lot of complications.<p>This might be the difference between a huge project and an ecosystem, and the question is where are people aiming with Rust support? If it&#x27;s just about drivers I can see some limited value in the ecosystem approach but it will be a tough sell for any Rust driver that wants its &#x27;M&#x27; in the kernel config.