Just as web developers, of all people, are finally, after over a decade, coming to the conclusion that arbitrarily-packaged dependencies are a bad idea for so many obvious reasons, Rust developers are trying to replicate NPM in the kernel.
I was told that Rust in the kernel would be a good thing, and that not much would change. If these are the types of people who are writing Rust for the kernel... can we go back? I really want to go back.
You could argue that there are some crates in the Rust ecosystem that suffer from a deep dependency tree, I don't think you can argue that Rust developers are trying to do this for the kernel.
The article states:
> The Rust-for-Linux developers understand this situation and are not envisioning adding the ability to pull in modules with a tool like Cargo
> You could argue that there are some crates in the Rust ecosystem that suffer from a deep dependency tree
Some? Dependency graphs of well over a hundred packages are ubiquitous. I've long since stopped being surprised when I compile a rust package that makes no network connections and see it (indirectly) pulling in multiple HTTPS libraries.
Right, great example. I think 'understand the situation' refers to this. I imagine the Rust for Linux developers would be going through any dependencies they pull in with a fine comb, in this case a dependency that pulls in HTTPS libraries for presumably no reason should be rejected. If that particular dependency makes it into the kernel, well, then you can start complaining about it. But right now feels a bit premature.
> Just as web developers, of all people, are finally, after over a decade, coming to the conclusion that arbitrarily-packaged dependencies are a bad idea for so many obvious reasons, Rust developers are trying to replicate NPM in the kernel.
Web developers and Rust developers are the same group
I'm sure there are web developers that are also Rust developers and vice versa, but the vast majority of developers I know that belong to either of those groups don't belong to the other.
Given it was born at Mozilla, is getting traction at WebAssembly and WebGPU efforts, WGSL is loosely based on its syntax, and some Cloud Native projects are migrating from Go to Rust, I am quite sure there is some overlapping.
Not that I agree with Rust's adoption at that level, as I think languages with automatic memory management make more sense, but that's me.
What people are roundaboutly observing is that the vast majority of developers these days either begin their career or spend at least a part of their career as web developers. That Rust is such a successful onramp to systems development even for people who haven't been classically trained in it is one of the strengths of the language.
While it is good that such people are embracing Rust for such purposes, they would have had a similar high level experience with something like Modula-2 or Object Pascal.
If anything, it is the pseudo-macro Assembler approach to C's design that made it a scary experience for some developers.
"related to" is doing a lot of work there. Browsers are "related to" the web, but surely you don't think Mozilla, if hiring for someone to work on the CSS layout engine or something for Firefox in c++ or rust, would advertise for a "web developer". It's just not the same job in any way.
Not any sort of developer myself but if you're writing an OS kernel, and for what it's worth, my opinion is you should know the library's your code relies upon is safe. I have to agree with the part of the article taking about bloat and security problems.
Just as web developers, of all people, are finally, after over a decade, coming to the conclusion that arbitrarily-packaged dependencies are a bad idea for so many obvious reasons, Rust developers are trying to replicate NPM in the kernel.
I was told that Rust in the kernel would be a good thing, and that not much would change. If these are the types of people who are writing Rust for the kernel... can we go back? I really want to go back.