The maintainer literally says the issue is that there are two languages. There is no way to convince them, there’s nothing anyone can do.
Which doesn’t help me a bit. Every additional bit that the another
language creeps in drastically reduces the maintainability of the kernel
as an integrated project. The only reason Linux managed to survive so
long is by not having internal boundaries, and adding another language
complely breaks this.
The maintainer didn’t say “I worry about the maintainability, please prove that it works outside the tree” (this concern was already discussed when the R4L experiment was officially OK’d). They are explicitly saying they’ll block Rust in the kernel, no matter what.
You’ve brought this up in several comments. given the situation, what do you think is the answer to replacing a huge c codebase with rust under the specific conditions of Linux development (open source, overwhelmingly maintained by 9-5 lifers employed by disparate organizations, in use everywhere for everything) when maintainers say they’ll oppose it?
Microsoft made the news a year or so ago announcing a rewrite of some libraries in rust, but conditions and limitations in Redmond are very different than those faced by the kernel team.
The maintainer literally says the issue is that there are two languages. There is no way to convince them, there’s nothing anyone can do.
Sure there is! Maintain your own tree, like I said. Eventually, it’ll be proven to be workable. Or not.
The maintainer didn’t say “I worry about the maintainability, please prove that it works outside the tree” (this concern was already discussed when the R4L experiment was officially OK’d). They are explicitly saying they’ll block Rust in the kernel, no matter what.
No, they aren’t. They are blocking how it’s being done, with R4L folks wanting to toss the maintenance headaches over the wall, for someone else to deal with, because they don’t want to build their own C interfaces, that match the already existing ones.
I don’t know how to better explain this to you.
Try to understand the problem better, so maybe you’ll be able to understand why maintaining your own tree to prove the conceptual implementation works, and doesn’t hand maintenance overhead to another party.
It will happen via it being better, and being shown to be better. And it will take time to unseat 30 years of C.
Not if they’re being prevented from showing to be better by C devs who, literally, “will do everything [they] can do to stop this”.
Nobody is trying to unseat 30 years of C.
Nobody prevents anyone from maintaining their own tree, thereby proving it works.
And yes, Rust is trying to replace C, in the kernel. Let’s start off by being honest here, k?
Yet the Linux project officially OK’d the R4L experiment, so why does this stuff still have to be kept out-of-tree?
No, Rust is not trying to replace C in the kernel.
Sure, why don’t you give it a try?
Yes, it’s been ok’d. That means it’s ok to go in, once proven.
So, R4L peeps need to figure out how to convince maintainers that is works.
So, go do it?
How do you convince a maintainer that NACKs a PR outside his subsystem while explicitly saying:
Please explain how one can convince such an individual.
I already did: maintain your own tree, and prove it out, that it’s better.
If the maintenance load is so light, it’ll be easy work to do, to keep the tree in line with upstream.
If it’s so obviously technically better, people will see it, and more people will push to mainline your tree.
It’s work. And you need to convince others on technical merit. So, do the work.
Just like what folks did with OpenBSD, the grsecurity tree.
The maintainer literally says the issue is that there are two languages. There is no way to convince them, there’s nothing anyone can do.
The maintainer didn’t say “I worry about the maintainability, please prove that it works outside the tree” (this concern was already discussed when the R4L experiment was officially OK’d). They are explicitly saying they’ll block Rust in the kernel, no matter what.
I don’t know how to better explain this to you.
You’ve brought this up in several comments. given the situation, what do you think is the answer to replacing a huge c codebase with rust under the specific conditions of Linux development (open source, overwhelmingly maintained by 9-5 lifers employed by disparate organizations, in use everywhere for everything) when maintainers say they’ll oppose it?
Microsoft made the news a year or so ago announcing a rewrite of some libraries in rust, but conditions and limitations in Redmond are very different than those faced by the kernel team.
Sure there is! Maintain your own tree, like I said. Eventually, it’ll be proven to be workable. Or not.
No, they aren’t. They are blocking how it’s being done, with R4L folks wanting to toss the maintenance headaches over the wall, for someone else to deal with, because they don’t want to build their own C interfaces, that match the already existing ones.
Try to understand the problem better, so maybe you’ll be able to understand why maintaining your own tree to prove the conceptual implementation works, and doesn’t hand maintenance overhead to another party.