This is not true. C code is allowed to break Rust bindings. The Rust For Linux folks will then go fix it. The C side was repeatedly told this, but doesn’t seem to want to hear it.
Nobody has decided what the post-experiment policy will be. A second language is new grounds for the kernel. Ted is assuming in order to interfere with the experiment.
Doesn't this mean that the change will have to be blocked until the Rust side is also fixed? Rust folks are eager to do it now, and there's a lot of "hype" around having Rust but is it going to be the same in, say, 15 years?
Userspace Rust is awesome ( aside from being a bit big), but I don't know if Rust in the kernel is proven yet (Time will literally tell).
You would think that by then either the Rust experiment has failed or the project has gained enough experienced developers such that maintaining such large refactors is feasible beyond heroics of the RfL folks. Either way it would be unlikely to be a problem then.
But in the meantime, how is the Linux project meant to evaluate what the maintenance burden is or wether the benefits outright the costs if the kernel maintainers doing the RfL work are being repeatedly stonewalled?
They said it, but it's a platitude - a lie. If this results in a broken kernel because the Rust part was not updated, the C change will be reverted to get a working kernel. This makes C maintainers de facto responsible for learning Rust to update the bindings.
That is simply not true. That is why Rust is an experiment currently: it is allowed to break. Compiling the Rust code at all requires an extra flag to be passed, so breaking Rust code never breaks normal builds.
They don't need to learn Rust. They could reach out and get help from someone that does. I'm sure the Rusteceans would be happy to if it got more support for C.
I'm not commenting on kernel dev specifically, just the general state of things.
I’ve only ever seen hostility from the C folks
I've seen that, too, but it looks to me that the hostility in that direction was a reaction to the hostility Rust folks have.
It takes two to tango, of course, but also devs are people, too. While it's not ideal, it's also understandable that people react poorly to being treated poorly.
The context being discussed here is what happened recently in the kernel. If that outburst’s root cause was Rust folks being jerks to the C folks, that’s very different than what seemingly happened.
I think both communities are too large and disparate to make sweeping claims like this in a more general sense, but I agree that people should not treat each other poorly.
Everyone is free to watch the video and make up their own minds, invoking religion instead of engaging with the actual technical aspects is aggressive, yes.
(Also, I was employed to write documentation, not do marketing, at least be accurate if you're going to try and smear me.)
I'm not smearing you. I'm stating that you are extremely biased - which you are.
invoking religion instead of engaging
Please, this is not the Mozilla mailing list. Don't bring the discussion to this kind of ground because you can't argue in good faith. You perfectly understood what I meant with zealots and it has nothing to do with religion here.
You perfectly understood what I meant with zealots and it has nothing to do with religion here.
I am referring to the video that this discussion is about, and that I referred to in the first half of that sentence, and what was said in it, not your zealotry comments.
It's entierely possible we might be talking past each other because I haven't seen the worst of what was said regarding the Rust integration by its opponents and you were not aware of all the comments I personally found unconstructive from the other side.
I am cognisant that it doesn't paint a very good picture of the kernel community as a whole.
I don’t particularly care about this discussion and I’m overall fairly sympathetic to what Rust tries to achieve but some of the claims made on the Linux ML by Rust zealots don’t help them. Memory safety through life cycle tracking is not the be-all end-all perfect solution to issues that some proponents paint especially in the kernel context and constantly painting C developers are irresponsible is probably not the wisest choice as a convincing strategy.
I am simply stating the facts of the situation, if you think that means that the C folks are irresponsible, that’s on you.
I do not think the C folks are being irresponsible. I think some of the C people are being obstinate, and deliberately trying to interfere with the experiment Linus asked to be carried out. There are others who have been quite supportive!
No, you are not. You are presenting your interpretation of the facts implying it’s truth in a way which is entirely typical of how Rust outreach has always been done. As usual, it’s more about emotion that facts. If you bring the Ruby playbook to a kernel discussion, you are not going to be well received.
Anyway, let me bit this bullet regarding the irresponsible comment:
"But I get the feeling that some Linux kernel maintainers just don't care about future code quality, or about stability or security any more […] They just want to keep their C code and wish us Rust folks would go away. And that's really sad... and isn't helping make Linux better."
That the Rust code is allowed to break, and that the Rust for Linux folks have agreed to fix it so that nobody who doesn't want to write Rust does not have to write Rust, is a fact.
I was merely stating that the Rust folks are going around stating that C developers who are not convinced that Rust is the way of the future are irresponsible. I never implied that the people were somehow forced to write Rust - even if it would be a logical conclusion of Rust becoming part of the kernel
at the end of the experiment considering the policy has always been that breakage is unacceptable.
I'm tempted to think that if you have to move the goal post so much maybe you are not the one being right in the conversation.
Note that I think that introducing Rust to the kernel with said policy might actually be a good thing. Rust has a lot of nice features (but so does Ada to be honest and I have yet to see anyone vehemently complain that Ada is not accepted in the kernel). I just extremely dislike the way the Rust community constantly oversell it and don't like seeing people like Ted Ts'o who have been huge contributors to the kernel being thrown mud at for perfectly understandable positions.
Comments
This is not true. C code is allowed to break Rust bindings. The Rust For Linux folks will then go fix it. The C side was repeatedly told this, but doesn’t seem to want to hear it.
As far as I understand it, that is only in the short term for the file system experiment where Rust is a "second class citizen" as Ted T'so put it.
Nobody has decided what the post-experiment policy will be. A second language is new grounds for the kernel. Ted is assuming in order to interfere with the experiment.
Doesn't this mean that the change will have to be blocked until the Rust side is also fixed? Rust folks are eager to do it now, and there's a lot of "hype" around having Rust but is it going to be the same in, say, 15 years?
Userspace Rust is awesome ( aside from being a bit big), but I don't know if Rust in the kernel is proven yet (Time will literally tell).
You would think that by then either the Rust experiment has failed or the project has gained enough experienced developers such that maintaining such large refactors is feasible beyond heroics of the RfL folks. Either way it would be unlikely to be a problem then.
But in the meantime, how is the Linux project meant to evaluate what the maintenance burden is or wether the benefits outright the costs if the kernel maintainers doing the RfL work are being repeatedly stonewalled?
No. It specifically is being treated as a second class citizen that is allowed to break.
Rust is already in the Windows kernel. It’s being used in embedded devices and kernels in production. It has proven itself.
They said it, but it's a platitude - a lie. If this results in a broken kernel because the Rust part was not updated, the C change will be reverted to get a working kernel. This makes C maintainers de facto responsible for learning Rust to update the bindings.
That is simply not true. That is why Rust is an experiment currently: it is allowed to break. Compiling the Rust code at all requires an extra flag to be passed, so breaking Rust code never breaks normal builds.
This is already the treatment given to out of tree kernel modules. Why not do the experiment out of tree?
Rust has already demonstrated its usefulness out of tree, with stuff like binder in Android and the GPU driver for the M1 with Asahi Linux.
With those successes, upstream is interested in seeing what Rust in-tree would look like. Hence the in-tree experimentation going on now.
They don't need to learn Rust. They could reach out and get help from someone that does. I'm sure the Rusteceans would be happy to if it got more support for C.
A lot of that might have something to do with the fact that the Rust community is incredibly hostile to the C community.
Can you show me where this is happening in the Linux project? I’ve only ever seen hostility from the C folks to the Rust folks.
I agree that in general the overall level of hostility in the kernel seems higher than ideal.
I'm not commenting on kernel dev specifically, just the general state of things.
I've seen that, too, but it looks to me that the hostility in that direction was a reaction to the hostility Rust folks have.
It takes two to tango, of course, but also devs are people, too. While it's not ideal, it's also understandable that people react poorly to being treated poorly.
The context being discussed here is what happened recently in the kernel. If that outburst’s root cause was Rust folks being jerks to the C folks, that’s very different than what seemingly happened.
I think both communities are too large and disparate to make sweeping claims like this in a more general sense, but I agree that people should not treat each other poorly.
With all due respect, you might not be completely neutral and unbiased here.
Then show me the evidence.
You also say “Rust zealots” above so you yourself (like frankly everyone) have bias as well.
You are the one implying the C developers are aggressing the Rust crowd, mr formerly professionally employed by the Rust project for outreach person.
Everyone is free to watch the video and make up their own minds, invoking religion instead of engaging with the actual technical aspects is aggressive, yes.
(Also, I was employed to write documentation, not do marketing, at least be accurate if you're going to try and smear me.)
I'm not smearing you. I'm stating that you are extremely biased - which you are.
Please, this is not the Mozilla mailing list. Don't bring the discussion to this kind of ground because you can't argue in good faith. You perfectly understood what I meant with zealots and it has nothing to do with religion here.
I am referring to the video that this discussion is about, and that I referred to in the first half of that sentence, and what was said in it, not your zealotry comments.
It's entierely possible we might be talking past each other because I haven't seen the worst of what was said regarding the Rust integration by its opponents and you were not aware of all the comments I personally found unconstructive from the other side.
I am cognisant that it doesn't paint a very good picture of the kernel community as a whole.
I don’t particularly care about this discussion and I’m overall fairly sympathetic to what Rust tries to achieve but some of the claims made on the Linux ML by Rust zealots don’t help them. Memory safety through life cycle tracking is not the be-all end-all perfect solution to issues that some proponents paint especially in the kernel context and constantly painting C developers are irresponsible is probably not the wisest choice as a convincing strategy.
I am simply stating the facts of the situation, if you think that means that the C folks are irresponsible, that’s on you.
I do not think the C folks are being irresponsible. I think some of the C people are being obstinate, and deliberately trying to interfere with the experiment Linus asked to be carried out. There are others who have been quite supportive!
No, you are not. You are presenting your interpretation of the facts implying it’s truth in a way which is entirely typical of how Rust outreach has always been done. As usual, it’s more about emotion that facts. If you bring the Ruby playbook to a kernel discussion, you are not going to be well received.
Anyway, let me bit this bullet regarding the irresponsible comment:
"But I get the feeling that some Linux kernel maintainers just don't care about future code quality, or about stability or security any more […] They just want to keep their C code and wish us Rust folks would go away. And that's really sad... and isn't helping make Linux better."
Asahi Lina
That the Rust code is allowed to break, and that the Rust for Linux folks have agreed to fix it so that nobody who doesn't want to write Rust does not have to write Rust, is a fact.
I was merely stating that the Rust folks are going around stating that C developers who are not convinced that Rust is the way of the future are irresponsible. I never implied that the people were somehow forced to write Rust - even if it would be a logical conclusion of Rust becoming part of the kernel at the end of the experiment considering the policy has always been that breakage is unacceptable.
I'm tempted to think that if you have to move the goal post so much maybe you are not the one being right in the conversation.
Note that I think that introducing Rust to the kernel with said policy might actually be a good thing. Rust has a lot of nice features (but so does Ada to be honest and I have yet to see anyone vehemently complain that Ada is not accepted in the kernel). I just extremely dislike the way the Rust community constantly oversell it and don't like seeing people like Ted Ts'o who have been huge contributors to the kernel being thrown mud at for perfectly understandable positions.