Indeed. The comment cited in the article is pretty stunning:
> Other crates that I'd like: anyhow, bincode, byteorder, log, once_cell, pin-project, rand, serde, slab, static_assertions, uuid plus some more esoteric ones.
This makes Rust devs look infantile, with no real understanding of what it means to develop for the kernel. Or what it takes to develop security and performance critical software of any kind, frankly.
Can you please elaborate? These crates are no_std and provide functionality which seems useful regardless of on the kernel or not.
I don't understand why it looks bad from a performance or security point of view. These crate are well established and developed by competant devs that also care about security and performance.
anyhow is for careless error propagation, where you know you won't do elaborate handling and just bubble it up to the user. It's suitable for (some) applications, but not for libraries, and a kernel falls on the "library" side of that divide. Errors should be handled by the kernel itself or reported carefully to userspace. anyhow is not built for that. (It also puts its errors on the heap—what do you do if memory allocation fails when reporting an error?)
Linux has its own UUID infrastructure, so it seems weird to pull in a whole parallel implementation. At the very least you'd want to disable all the generation code, and it's unclear to me if the uuid crate supports that.
rand is large. Does Linux need all the probability distributions it supports? (ripgrepping for "Bernoulli" only turns up the name of a floppy disk system, so probably not.) Doesn't it already have an implementation for the ones it does need?
> It's suitable for (some) applications, but not for libraries, and a kernel falls on the "library" side of that divide.
I would disagree with that assertion: the kernel is a service that end user applications interact with through an API. Using anyhow in a Rust library that Rust applications use is a very bad idea. Using anyhow in the kernel might be a bad idea, but not for that stated reason.
> Linux has its own UUID infrastructure, so it seems weird to pull in a whole parallel implementation. At the very least you'd want to disable all the generation code, and it's unclear to me if the uuid crate supports that.
The uuid crate can be modified to support the kernel infrastructure as its backend. This would allow the same API to be available within the kernel and in the rest of the ecosystem. That's beneficial to everyone involved.
> the kernel is a service that end user applications interact with through an API.
My thinking is that that API has to distinguish between many strictly defined error codes, while anyhow homogenizes errors and focuses on human-readable information. How would you tell whether an anyhow::Error means EINVAL or EFAULT?
It's the same fundamental design tradeoff that makes it unsuitable for Rust libraries, even if anyhow wouldn't be visible in the public API.
> The uuid crate can be modified to support the kernel infrastructure as its backend
Fair enough, using a modified version seems reasonable.
Actually all of those crates could potentially be implemented in the kernel and be useful. The current implementations wouldn't work as-is, in many cases, but the APIs make sense and the crate could use conditional compilation to work in the kernel.
The most far-fetched crate there would be pin-project I think, because a lot of other work would have to be done to make Rust async code work in the kernel.
>The most far-fetched crate there would be pin-project I think, because a lot of other work would have to be done to make Rust async code work in the kernel.
Pin's usefulness is not limited to async. Any type that contains a pointer relative to itself benefits from being wrapped in it to avoid accidental misuse.
Most Rust "crates" are compile-time convenience features that add comparatively little binary code to the final build. The requests are plenty reasonable from that POV, although "vendoring" the deps might still introduce some complexity.
i mean, serde in the kernel is overkill, but not every crate is like that. Rust has been designed in the internet era and leverages dependencies for things older languages would ship with (rand!)
> Weird justification for missing an extremely central and extraordinarily important feature
Can you think of any reason why decoupling it from the language itself would be a good idea? Why does it need to be baked in, and what problems would arise if it was? How do these problems trade off against having people just run “cargo add rand”?
> Other crates that I'd like: anyhow, bincode, byteorder, log, once_cell, pin-project, rand, serde, slab, static_assertions, uuid plus some more esoteric ones.
This makes Rust devs look infantile, with no real understanding of what it means to develop for the kernel. Or what it takes to develop security and performance critical software of any kind, frankly.