Filesystem in Rust - Kent Overstreet

> A passive-aggressive exit, but not unusual compared to other Rust drama. By Linux kernel drama standards, it was a non-event. You have the video segment in text, it was pretty non-technical. "NO! We don't want to encode what our assumptions are! We don't want to learn Rust. What do you mean write down our assumptions?" [VIDEO]

i encourage everyone to watch the linked video [0]. reminds me of the recent non-technical arguments made in the freebsd thread [1]. git mailing lists have such a greybeard IRC vibe to them. i will, from now on, use "only accepts patches per mail" as a proxy for "not worth suggesting new ideas to" for all projects. it's a stupid proxy. correlation and causation and all that. but it's a very useful one for your sanity. [0] [VIDEO] [1] [LINK]

yeah, here is the message on lkml [ [LINK] ] ''' Hey folks, This is as short a series as one can be: just removing myself as maintainer of the Rust for Linux project. I am retiring from the project. After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them. To the Rust for Linux team: thank you, you are great. It was a pleasure working with you all; the times we spent discussing technical issues, finding ways to address soundness holes, etc. were something I always enjoyed and looked forward to. I count myself lucky to have collaborated with such a talended and friendly group. I wish all the success to the project. I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix. Lastly, I'll leave a small, 3min 30s, sample for context here: [VIDEO] -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code. Thanks, -Wedson '''

Also linked in the email in the GP. > Lastly, I'll leave a small, 3min 30s, sample for context here: [VIDEO] -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code.

That video snippet which was posted by that former Rust/Linux maintainer has an excellent example: [VIDEO] The return type of that get_or_create_inode() function is: Result<Either<ARef<INode<T>>, inode::New<T>>> I'd say that's a pretty good example for 'hideous'. It looks like some of the worst C++ code I've seen and then quickly tried to forget. If stuff like this ends up in the Linux kernel I would be pissed too as a Linux kernel greybeard.

> starting a project out of grudge How many times has this succeeded for fundamental work? I can think of a couple, including Xorg and GCC. I don't know if those cases can be characterized as "grudges" exactly but, in each instance, someone was unsatisfied with the prevailing conditions, forked the work, and then subsumed the legacy. Doubtless there have been far more failures than successes. I also know that computing probabilities based on such ratios is simple minded: other factors exist and the equation is non-linear. > But I think Linux isn't at that position yet. I was disturbed by the irrational behavior I saw in this talk[1]. What the presenter sought was reasonable: communicate the intended semantics so Rust kernel developers can track the evolution. This was somehow understood as: forego C and become a Rust programmer, take responsibility for our work and maintain it going forward. No, I do not believe the former implies the latter. There are endless silos, both formal and informal, for both good reasons and bad reasons, permeating all intellectual work, whether "open" or not. It is entirely reasonable to imagine that this pattern can be employed among reasonable people for the matter at hand, especially for something like file systems, where even parallel implementations can and do exist simultaneously. If this behavior is prevalent enough then drastic steps are justified. Whether they're feasible or not is another matter, and also a many factored, non-linear calcu

Filho's exit message had this point: Lastly, I'll leave a small, 3min 30s, sample for context here: [VIDEO] -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code. First comment to this article is insightful. >The “file system maintainer” had a more legitimate question than most comenters have allowed. Under Linus’s rules for maintainers, when an intrface is changed it is the responsibility of the person requesting the change to submit patches for all other uses of the interface. That requires the “filesystem maintainer” to patch Rust code – which he is unqualified to do. That means he can no longer change any interface, which is a big change in Linux policy that Linus would need to address. It seem that Filho is not correct in his statement. There must be policy change or maintainers must be forced to learn Rust.

For those curious, this is the link[0] to the filesystems talk with the relevant timestamp. A bit more was discussed in this[1] article as well about Wedson Almeida Filho leaving. [0]: [VIDEO] [1]: [LINK]

It's also not truthful because many of the Rust maintainers are long time C contributors. Marcan also linked to this resignation of a Rust Maintainer: [LINK] which references this fantastic exchange: [VIDEO] I am not a C person, or a kernel level person, I just watch this from the sideline to learn something every now and then (and for the drama). But this exchange is really stunning to me. It seems so blatantly obvious to me that systematically documenting (in code!) and automatically checking semantic information that is required to correctly use an API is a massive win. But I have encountered this type of resistance (by very smart developers building large systems) in my own much smaller and more trivial context. To some degree, the approach seems to be: "If I never write down what I mean precisely, I won't have to explain why I changed things." A more charitable reading of the resistance is: Adding a new place where the semantics are written down (code, documentation and now type system) gives one more way in which they can be out of sync or subtly inconsistent or overly restrictive. But yeah, my intuitive reaction to the snippet above is just incredulity at the extreme resistance to precisely encoding your assumptions.

> And then he can't help himself. After being so reasonable, he throws shade on Rust. Shade that is just unfortunately, just false? Many discussions online (and offline) suffer from a huge-group of people who just can't stop themselves from making their knee-jerk reactions public, and then not thinking about it more. I remember the "Filesystem in Rust" video ( [VIDEO] ) where there are people who misunderstand what the "plan" is, and argue against being forced to use Rust in the Kernel, while the speaker is literally standing in front of them and saying "no one will be forced to use Rust in the Kernel". You can literally shove facts in someone's face, and they won't admit to being wrong or misunderstand, and instead continue to argue against some points whose premise isn't even true. I personally don't know how to deal with this either, and tend to just leave/stop responding when it becomes clear people aren't looking to collaborate/learn together, but instead just wanna prove their point somehow and that's the most important part for them.

I would be more likely to want to listen to T'so if he hadn't done the following: [VIDEO] There was a reasonable discussion about Rust, and then T'so drops the bombshell: "I suspect part of the problem here is you're trying to convince everyone to switch over to the religion as promulgated by Rust and the reality is that ain't going to happen because we have 50 plus file systems in Linux they will not all be instantaneously converted over to rust" [26:05] He pretty much shouts at the Rust developers, denigrates their efforts and when they explain what they are trying to do which is to understand the semantic changes. And then T'so then starts yelling at him even more. He wonders why people are not happy with his attitude - then perhaps he should consider how he communicates. The Rust guy is trying to be constructive and T'so was not.

"Rust also gives us the ability to define our in-kernel apis in ways that make them almost impossible to get wrong when using them. We have way too many difficult/tricky apis that require way too much maintainer review just to "ensure that you got this right" that is a combination of both how our apis have evolved over the years" Funny, that's not Theodore T'so's position. The Rust guys tried to ask about interface semantics and he yelled at them: [VIDEO]

> You can't go around screaming "your code SUCKS and you need to rewrite it my way NOW" It seems you are imagining things and hate people for the things you imagined. In reality there are situations where during technical discussions some people stand up and with trembling voice start derailing these technical discussions with "arguments" like "you are trying to convince everyone to switch over to the religion". [VIDEO]

Its in a talk about File systems in Rust for Linux. Basically the rust maintainer who I think stepped down was talking about how the C-code base for VFS has a lot of documented but complex orderings where you have to call a lock, or pin before accessing an Inode(or something) one way but not the other. They made a bunch of Rust Types so you basically could not produce an illegal ordering and got heckled pretty hard by the "bearded guy". They basically run out the presentation time with heckling and I think the Rust maintainer quit a few months later (over many similar instances of this. don't quote me time line here) [source] [VIDEO]

> how considerate Ted Tso's writing always is This is less true when T'so asks questions at conferences, of course. [LINK] [VIDEO]