[ddevault]

I think I addressed this in the footnote:

> There are some other arguable benefits which mainly boil down to finding Rust to have a superior language design to C or to be more enjoyable to use. These are subjective and generally are not the most important traits a kernel hacker has to consider when choosing a language, so I’m leaving them aside for now.

I agree that these features are nice; I added many of them to my own language and take advantage of them in my kernel. But they are a secondary concern to the constraints of the kernel's problem space and the conservatism required of a project like Linux.

[iudqnolq]

In general, you seem to be arguing kernel programming shouldn't be nice.

Why wouldn't things being easier lead to better results, all else equal?

[ddevault]

Because all things are not equal, unfortunately. Per the article:

> As Linus recently put it, “kernel needs trump any Rust needs”. The kernel is simply not an environment which will bend to accommodate a language; it must go the other way around.

[iudqnolq]

If Linus had said "rust can't accommodate the idea kernel needs nead to trump rust needs", I'd buy what you're saying.

That line came from Linus educating a single wrong member of the rust community.

It only shows that person wasn't using rust in a way that accommodated kernel needs, not that it's impossible or even difficult to do so.

[varajelle]

What are these "rust needs" that are incompatible with "kernel needs"?

Stuff like faillible memory allocations are being worked and rust doesn't have so many needs by itself.

[iudqnolq]

A single person argued to Linus a broad amount of the kernel's internal API should be painstakingly refactored to be philosophically rust-y. Linus said no way, that's not what we're doing here.

Luckily, that's not what the Rust for Linux project has been doing either.