[pseudony]

That should be obvious ?

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]

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.

[rc00]

This is a horrible comment, much like many of the others on this thread. The long-time contributors to the Linux kernel project have been doing so before there was any "prestige" or resume credentials attached. And if it was just about a resume, wouldn't they have moved on already? This is an ill-conceived take and just another example of some of the pro-Rust crowd being far too unknowledgeable to be upset.

[laerus]

You are not convincing me that these people care about the longevity of the project when they are so smug and ready dismiss anything that is not fitting their whatever agenta, even if that is a supposedly passion for contribution and development.

What you don't understand about what you call "pro-Rust crowd" is that there is a reason to push for memory safety and encoding the invariants in the type-system. It's the closer you can get to a mathematically proven system.

If you don't want one of your most core systems to be as robust as possible against security vulnerabilities, even if that means going out your way either learning something unfamiliar or god forbit communicating, like you have more emotional quality than a potato, with other people then you are a horrible person.

[masfoobar]

Linus Torvolts fairly recent comment regarding Rust:-

"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]

> 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.

[steveklabnik]

At present it doesn’t even slow down the merge! The whole point of the experiment is to get experience without interfering with the regular development of the kernel. It’s allowed to be broken by non-Rust work, and as you mentioned the Rust folks are wiling to do the work on that side.