The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover.
If I am contributing to the Linux kernel already, I presumably have a decent grasp of C, the central abstractions in the code I am changing, the email-based patch workflow and so on.
So when my code breaks adjacent code, I should have a good chance of fixing those issues also, and most often, this won't become the main body of work.
If jamming in Rust bindings means the great mass of existing contributors are forced to learn Rust, whether they wish or not, to either maintain bindings or to drop out altogether, then raising the pitchforks is not an unreasonable response.
Well then raise these concerns and find a way to solve them together. Not dismiss a proven solution to real and even dangerous problems like memory unsafety.
It's unreasonable for educated grown men to react like 12yo children and resist change cause "we don't like eating our vegetables even though they are good for our health". If you actually care about the Linux kernel you will find a way forward even if that means communicating with people or even changing habits.
At the end of the day I don't think that the people that are contributing to the Linux Kernel do it out of good will but rather more about than prestige and building a resume. Or else we wouldn't have this resistance to progress.
"I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different. So there's been some pushback on Rust."
I do wonder if peoples mindset, especially kernels developers, would have a change of tune if Linus himself goes out of his way to learn Rust.
I doubt he is and, likely, has no interest in learning it, either. He is not in the position where he is forced to for the most part. However, from what I remember, he does review a lot of code and makes the final decision what gets merged into the main branch. I wonder how much use he will be when... perhaps in the next 10 years... the lower-level code he review becomes more and more Rust.
I guess by then -- which I covered a little in my comment on here -- is likely to be retiring by then.
I just think Linus, the guy that would says there is "Nothing better than C!" - could change the culture in the kernel world if he becomes decent at Rust programming. In reality, I think he would get annoyed fighting the borrow checker. Maybe I would be proven wrong.
> The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover.
No, it just means that when their changes are ready, if they break the Rust bindings then then just need to fire off an email to the Rust people to update the binding. This is no different than having to get an approval before merging a branch. They don't have to code differently at all. It just slows down the merge. That's it.
pseudony|1 year ago
The concern from those contributors (and we might soon see the same in QEMU) is that these bindings are essentially a weaponization which forces the great majority of contributors to learn Rust or drop out. Essentially a hostile takeover.
If I am contributing to the Linux kernel already, I presumably have a decent grasp of C, the central abstractions in the code I am changing, the email-based patch workflow and so on. So when my code breaks adjacent code, I should have a good chance of fixing those issues also, and most often, this won't become the main body of work.
If jamming in Rust bindings means the great mass of existing contributors are forced to learn Rust, whether they wish or not, to either maintain bindings or to drop out altogether, then raising the pitchforks is not an unreasonable response.
laerus|1 year ago
It's unreasonable for educated grown men to react like 12yo children and resist change cause "we don't like eating our vegetables even though they are good for our health". If you actually care about the Linux kernel you will find a way forward even if that means communicating with people or even changing habits.
At the end of the day I don't think that the people that are contributing to the Linux Kernel do it out of good will but rather more about than prestige and building a resume. Or else we wouldn't have this resistance to progress.
masfoobar|1 year ago
"I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different. So there's been some pushback on Rust."
I do wonder if peoples mindset, especially kernels developers, would have a change of tune if Linus himself goes out of his way to learn Rust.
I doubt he is and, likely, has no interest in learning it, either. He is not in the position where he is forced to for the most part. However, from what I remember, he does review a lot of code and makes the final decision what gets merged into the main branch. I wonder how much use he will be when... perhaps in the next 10 years... the lower-level code he review becomes more and more Rust.
I guess by then -- which I covered a little in my comment on here -- is likely to be retiring by then.
I just think Linus, the guy that would says there is "Nothing better than C!" - could change the culture in the kernel world if he becomes decent at Rust programming. In reality, I think he would get annoyed fighting the borrow checker. Maybe I would be proven wrong.
Pet_Ant|1 year ago
No, it just means that when their changes are ready, if they break the Rust bindings then then just need to fire off an email to the Rust people to update the binding. This is no different than having to get an approval before merging a branch. They don't have to code differently at all. It just slows down the merge. That's it.