The full quote: > You're trying to convince everyone to switch over to the religion as promulgated by Rust, and the reality is that ain't gonna happen because

The full quote: > You're trying to convince everyone to switch over to the religion as promulgated by Rust, and the reality is that ain't gonna happen because we have 50+ filesystems in Linux. They will not all be instantaneously converted over to Rust. Before that happens, we will continue to refactor C code because we want to make the C code better. If it breaks the Rust bindings, at least for the foreseeable future, the Rust bindings are a second class citizen, and those filesystem that depend on the Rust bindings will break, and that is the Rust bindings problem, not the filesystem community at large problem, and that's going to be true for a long long time. And I think we just simply need to accept that, because the answer "you are not allowed to refactor the C code because it would break 5 critical filesystem that distros depend upon" is not a starter. So we'll see; I suspect the best thing to do is for you to continue maintaining your Rust bindings. Over time, there will be continued C code refactoring -- maybe we will start using kfree RCU. If that breaks Rust, we will find out whether this concepts of encoding huge amount of semantics into the type system is a good thing or a bad thing, and instead of trying to convince us to what is actually correct, let's see what happens in a year or two. And it will either work or it won't, and we will see, more likely, where does the pain get allocated. Because with most of these sort of engineering things it's almost always a pain allocation question. > [...] > You're not going to force all of us to learn Rust -- if I make a change, I will fix all of the C code, because that's my responsibility. Because I don't know Rust, I'm not going to fix the Rust bindings. Some of his language is more emotionally charged than was productive, sure, but I think his underlying concern is reasonable: most kernel maintainers don't know Rust, and so when they make changes to C code, they won't be able to fix Rust clients of that C code. The Rust maintainers accept this, and agree to take responsibility for updating Rust code to match changes in C (which is contrary to the usual development workflow of the kernel, hence the concern over what happens if major distros start depending on Rust code). Note also that Ts'o isn't objecting to including Rust in the kernel! His recommendation is to ship the Rust bindings and see "where the pain gets allocated" as the C code continues to evolve. (The idea being that either Rust's type system and borrow checker will make it easy to identify semantic breakages early, thus making Rust code lower-maintenance than C, or the Rust bindings will turn out to be fragile and high-maintenance, and that the best way to tell is by waiting to see). I'm not a part of the Linux kernel community at all, and I certainly don't know all the context that led to Almeida leaving the project -- I imagine Ts'o's comments were a "straw that broke the camel's back" kind of thing. But the Linux kernel is a complex project and critical infrastructure, so surely concerns about organization and maintainability need to be hashed out before Rust can make it to production. Also, Ts'o's comments struck me as some of the most reasonable out of that talk, at least from a technical perspective -- the next commenter after Ts'o objects to Rust in the kernel on the basis that its function call syntax reminds him of Java.