Regretfully a major Rust for Linux maintainer just stepped down yesterday, saying he doesn't have the energy to keep dealing with the constant nontechnical nonsense: https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@...
These people, while well intentioned in pushback, have difficulty separating benefit to the entity and benefit to themselves. So it takes a lot of work to impact change, and I understand the distance it has from normal technical work.
It's probably more difficult to handle in open source than in a company because authority less powerful and it's more difficult to wave both carrots and sticks...
The dev "pushing back" was being an asshole probably because of deep insecurity of gasp there being other programming languages than C.
Literally rust is currently being proposed for maybe new drivers and basically nothing else ATM. Nobody is suggesting rewriting code in rust or forcing people to learn rust. It is literally just "Hey, might be nice to write this driver for my mouse in a memory safe language".
He did a presentation on making a fs in rust, the response from this dev was "we won't be converting to your religion. We are going to continue modifying c code and your dumb rust code will always be a second class citizen."
Literally just hostility for hostility sake. He wasn't proposing to rewrite everything in rust. He wasn't proposing that everyone learns rust. He was just giving a freaking presentation on making a rust fs that integrates with the kernel and was immediately trashed for spreading religion or whatever.
Non-technical nonsense is charitable.
> 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 filesystems in Linux, they will not all be instantaneously converted over to rust. Before that happens we will continue to refactor code because we want to make the C code better. If it breaks rust bindings, at least for the foreseeable future the rust bindings are a second class citizen and those file systems that depend on the rust bindings will break and that is the rust bindings problem, not the file system community at large's problem and that's going to be true for a long long time, okay, and I think we just simply need to accept that
That seems rather technical to me. To put words into their mouth because they had a snarky tone, or claim the presenter was "immediately stacked for spreading religion or whatever" hardly is.
From the closed captions with minor editing. In response to "we are going to provide API bindings"
> I suspect the problem here is you are trying to convert everyone to the religion as promulgated by rust and the reality is that ain't gonna happen. Because we have 50 plus filesystems in linux and they will not all be instantaneously converted over to rust. Before that happens we will continue to refactor code because we want to make C code better. If that breaks the rust bindings at least for the foreseeable future the rust bindings are a second class citizen. Those file systems that depend on the rust bindings will break and that is the rust bindings problem not the file system community at large problem. And that's going to be true for a long long time, OK. And I think we just simply accept that right because the answer you are not allowed to refactor C code because it would break 5 critical file systems that distros depend on is like not a star, OK.
And that critique is near the end of all the people who asked questions or made comments. So no, the presenter wasn't "immediately stacked" when making that presentation.
If you'll re-read the quote you claim to be literally quoting, nowhere does it say "spreading your religion":
> > I suspect the problem here is you are trying to convert everyone to the religion as promulgated by rust...
The other reason Linux is trustworthy because of the technical meritocracy culture. But since Rust is not a technical choice, as Rust cannot per-se do things that are impossible in C - you can do anything in C - the introduction of Rust falls outside the parameters of the regular rough-but-mostly-fair Linux exchanges. This leading to toxic reactions from the less socially-abled.
Have anything in particular in mind? It's been my understanding that Rust actually can do everything C can, but the additional safety guarantees imposed by the type system make it a bit harder.
A comment there has a link to a video of what seems to be the final straw.
> Lastly, I'll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code.
0: https://www.reddit.com/r/linux/comments/1f3q0l8/one_of_the_r...
If kernel includes Rust, then that C code change could also require applying fixes to Rust code that breaks from that change
It's a little tough to build a safe abstraction layer on top of C or encourage maintainers to stick around with a hostile "that's a _you_ problem" mentality or inaccurate rhetoric that Rust are trying to force their religion onto the C devs.
https://lwn.net/Articles/978738/
While I disagree with his opinions here, Ted T'so is a long-time Linux kernel dev. He's been around since close to the beginning.
I have not seen many of those in my close to 32 years of involvement with Linux. In the beginning of the project they did occur 'every now and then' but once Linux got past v1.2 or thereabouts they're about as rare as hen's teeth. If Rust ever becomes widespread enough for kernel developers to pick it up with ease it will be a welcome addition but until such a time I prefer for the project to remain C-focused so as not to close out a large fraction of the potential developer base. If that means that some 'competing' kernel gets written in Rust and takes over from Linux that'd be fine by me as well, may the best [1] kernel win.
Suggesting making a new kernel is just total FUD. This is a multi decade project. It's like saying to a person who want some legislation in their country to change "why not make your own country, may the best country win". It's just so far removed from reality I'm very surprised I have seen this argument more then once.
Linux started as a hobby project of a single student and just a few years later it was already possible to build a full-blown UNIX desktop system with Linux as kernel.
Why should that not be possible to replicate today? Especially with modern development tooling and a big and motivated language community?
What is missing is the user base! When Linus started his project, many people knew Unix in their professional life and were disappointed with what the market (M$) was proposing for the personal computer world.
Today, no such multitude is waiting for the next Linux.
Linux may not be perfect, but it's definitely good enough.
That doesn't even begin to touch on the problem that linux came at just the right time.
Replacing any substantial parts of the Linux project with Rust also would be multi-decade effort, most likely more effort than forking off a separate evolutionary branch (which is probably the most realistic option). Such forks happened all the time in the history of UNIX.
No one wants to replace substantial parts of the linux project with Rust. This is a straw man, and the same bad faith argument the set in their ways kernel greybeards are making. People just want to be able to write green field drivers in Rust.
As long as they are the majority of the kernel developers, their wish is what matters the most.
This problem is not expected to be solved by current maintainers. They're just asked to make room for the next generation. "It should hurt you like it hurt me" is not an acceptable response.
> Does the proverbial rust programmer who doesn't know C even exist?
I have seen enough Python or JS programmers learning Rust without having any working knowledge about C. Of course Rust is not an easy language to learn for them, as they have to deal with a concept of explicit memory and lifetime that have no equivalent in Python or JS, but otherwise I didn't see any complication specific to Rust.
The rust guys were just asking for semantic information about the current C apis so they could try to encode them into the type system.
All they got in response to that were made up problems of them supposedly forcing everyone to adopt their religion, rust being too OOP or other nitpicks that had nothing to do with the issue the presenters were trying to talk about.
Nobody even answered their questions, people which obviously didn't even look at rust for more than an hour gave their opinion on why what they're doing is bad and destined to fail. It was rude, tone-deaf and not a single technically sound argument was actually made.
I love linux and I'm fine with the maintainers deciding to use C if they want to, but the behavior by the old guard here was actually appalling and reeks of deep insecurity and inability to communicate.
Since when is Rust a requirement to help Linux development? Only an utter idiot could think that such a big and successfully community would put any effort in addressing any issue that is not posed in their natural language!
If you want to introduce Rust into Linux, you learn C, you learn Linux, you add and maintain whatever you want.
It's not and it shouldn't be, but it is most definitely required if you want to criticize it's integration into the kernel due to its supposed flaws/merits in a "technical" discussion.
Nobody is forcing anyone to learn rust, the RiL folks are fine with maintaining bindings and handling the fallout of C API changes. They didn't even get to say that, because they were shouted at for asking a question.
> If you want to introduce Rust into Linux, you learn C, you learn Linux, you add and maintain whatever you want.
Which is basically exactly what the RiL community is doing. In the posted video you can see them TRYING their best to learn about the undocumented invariants of a C API and getting nothing but flak for it for completely made up reasons. I might be hard to understand, but many of the strongest advocates of rust know C well and are opposed to using it themselves for good reasons. The folks maintaining C API don't have to care much about the rust part, except maybe giving a friendly heads-up when they change API's they depend on, like you would in any kernel development work where you are impacting another subsystem.
Apparently this is too much to ask from some of these C grandpas.
While these guys have undoubtedly made great contributions to Linux and FOSS and I'll be forever thankful for that, some of their behavior towards the RiL community has been appalling and petty. They have been resistant to any sort of change, even if it does not impact them at all, are quick to criticize without any attempt at understanding the efforts and benefits of Rust integration or even making any technically coherent argument. Constructive criticism and open discussion is important, but it should be based on accurate information and a willingness to learn instead of knee-jerk reactions and reacting to people wanting to learn about the API of your subsystem with outright and unwarranted hostility.