(n.b. I am neither a rust, nor C developer so I am writing outside my own direct experience)
One of the arguments brought up on the kernel.org thread was that if there were changes to the C side of the API, how would this avoid breaking all the rust bindings? The reply to this was that like with any big change in the Linux kernel that affects multiple systems with multiple different teams involved, that it would require a coordinated and collaborative approach — i.e. it’s not like the rust side of things would only start working on responding to a breaking change once that change has broken the rust bindings. This response (and many of the responses to it) seemed reasonable to me.
However, in order for that collaboration to work, there are going to have to be C developers speaking to rust developers, because the rust developers who need to repair the bindings will need to understand some of what’s being proposed, and thus they’ll need to understand some level of C, and vice versa. So in practice, it seems nigh on impossible for the long term, ongoing maintenance of this code to be entirely a task for the rust devs (but I think this is taking an abnormally flexible reading of “maintenance” — communicating with other people is just part and parcel of working on such a huge project, imo)
Some people have an ideological opposition to there being two different programming languages in the Linux kernel full stop. This is part of why the main thing that rust has been used for so far are drivers, which are fairly self enclosed. Christoph Hellwig even used the word “cancer” to describe a slow creep towards a codebase of two languages. I get the sense that in his view, this change that’s being proposed could be the beginning of the end if it leads to continued prevalence of rust in Linux.
I haven’t written enough production code to have much of an opinion, but my impression is that people who are concerned are valid (because I do have more than enough experience with messy, fragmented codebases), but that their opposition is too strong. A framework that comes to mind is how risk assessments (like are done for scientific research) outline risks that often cannot be fully eliminated but can be reduced and mitigated via discussing them in the context of a risk assessment. Using rust in Linux at all hasn’t been a decision taken lightly, and further use of it would need ongoing participation from multiple relevant parties, but that’s just the price of progress sometimes.
If the rust devs are willing to take on that work, what’s the problem?
(n.b. I am neither a rust, nor C developer so I am writing outside my own direct experience)
One of the arguments brought up on the kernel.org thread was that if there were changes to the C side of the API, how would this avoid breaking all the rust bindings? The reply to this was that like with any big change in the Linux kernel that affects multiple systems with multiple different teams involved, that it would require a coordinated and collaborative approach — i.e. it’s not like the rust side of things would only start working on responding to a breaking change once that change has broken the rust bindings. This response (and many of the responses to it) seemed reasonable to me.
However, in order for that collaboration to work, there are going to have to be C developers speaking to rust developers, because the rust developers who need to repair the bindings will need to understand some of what’s being proposed, and thus they’ll need to understand some level of C, and vice versa. So in practice, it seems nigh on impossible for the long term, ongoing maintenance of this code to be entirely a task for the rust devs (but I think this is taking an abnormally flexible reading of “maintenance” — communicating with other people is just part and parcel of working on such a huge project, imo)
Some people have an ideological opposition to there being two different programming languages in the Linux kernel full stop. This is part of why the main thing that rust has been used for so far are drivers, which are fairly self enclosed. Christoph Hellwig even used the word “cancer” to describe a slow creep towards a codebase of two languages. I get the sense that in his view, this change that’s being proposed could be the beginning of the end if it leads to continued prevalence of rust in Linux.
I haven’t written enough production code to have much of an opinion, but my impression is that people who are concerned are valid (because I do have more than enough experience with messy, fragmented codebases), but that their opposition is too strong. A framework that comes to mind is how risk assessments (like are done for scientific research) outline risks that often cannot be fully eliminated but can be reduced and mitigated via discussing them in the context of a risk assessment. Using rust in Linux at all hasn’t been a decision taken lightly, and further use of it would need ongoing participation from multiple relevant parties, but that’s just the price of progress sometimes.
It will take more effort than writing kernel from scratch. Which they are doing anyway.