[blacksmithgu]

I respect the opinion in this article that Linux should be simple and Rust is adding a lot of complexity to the build and ABI, but the advantage of Rust is not just memory safety.

Rust is massively more expressive. You get actual tagged enums, modules, sane dependency management, generics, polymorphism, optionals, no unchecked nullability, collections, and many other things. Writing systems software with it - even if you completely ignore memory safety! - is a very pleasant experience once you've grokked the language.

[arunc]

> Rust is massively more expressive

Albeit it is subject, compared to C, yes.

Not so much compared to D.

[morio]

> Rust is massively more expressive.

The question is not if Rust is more expressive but if C is expressive enough for the Linux kernel. So far there is no evidence that Rust adds any value here. And if C is missing certain features, they can be added. It looks like ISO is looking at that very thing in C2x and beyond.

[varajelle]

C might be enough, but Rust is better. Rust makes programming more productive. Are you denying that? And C is not going to get Rust features: C's philosophy to stay limited on purpose.

[Shikadi]

Security?

[rust_is_dead]

With such expressivity, there is a risk in a big project of individuals conjuring wildly different mechanisms to express similar if not identical ideas, losing out on understandability and consistency. The solution is often a strong style guide that everyone must read and follow. If Rust ever makes it to the kernel, I hope such a guide is written...

[varajelle]

But you have the same problems in C, even worse.

Because you need to emulate in C the features that more advanced languages have buitin, such as virtual tables, tagged union, lists, hash map, and whatnot. This is just a lot of conventions that are specific to each project that need to be learned and put in some style guide or development guide. In big projects, different developers will use different conventions in different part of the code, that's unavoidable.

[nwah1]

I would think that the extremely complicated algorithms that are often used are just intrinsically difficult, and things like metaprogramming allow a lot of expressivity in C already.

Having to think through race conditions is likely more of an issue than having to think through 3 obvious but distinct ways of doing the same thing syntactically.

Even though I would prefer there be only one obvious way to do things.

[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.