Comment by nindalf

As of today, the burden is uncertain and the Rust crowd has not been fixing things quickly enough since they are manual fixes:

https://lore.kernel.org/rust-for-linux/20250131135421.GO5556...

> Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not.

> Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders".

> It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build.

For clarity, tree-wide fixes for C in the kernel are automated via Coccinelle. Coccinelle for Rust is constantly unstable and broken which is why manual fixes are required. Does this help to explain the burden that C developers are facing because of Rust and how it is in addition to their existing workloads?

They've said that, but nobody believes them, and can you blame them given we JUST saw another big rust maintainer resign?

I'd be suspicious these guys aren't in it for the long haul if they don't get their way and will leave the Rust they shoved in the kernel to bit rot if things don't go their way w.r.t enough rust adoption fast enough. "If you don't let us add even more rust, we will resign from the project and leave you to maintain the rust that's already there and that we added, and that you said you didn't want to add because you didn't trust us to not resign".

Rust 4 Linux people just proving the points of the maintainers scared of abandonment.

The rust 4 Linux people unfortunarely give the impression of caring more about rust than about the kernel, and it's clear that many are willing to make that perfectly clear by abandoning the larger project.

The whole thing needs to be scrapped and rethought with better and more committed leadership. This past 6 months to a year has been embarrassing and done nothing but confirm the fears of anti rust people.

This is not what the "Rust kernel policy" [1] of Rust for Linux says.

[1]: https://rust-for-linux.com/rust-kernel-policy

> Who is responsible if a C change breaks a build with Rust enabled?

> The usual kernel policy applies. So, by default, changes should not be introduced if they are known to break the build, including Rust.

> Didn't you promise Rust wouldn't be extra work for maintainers?

> No, we did not. Since the very beginning, we acknowledged the costs and risks a second language introduces.

This is not how the kernel works. You cannot rely on someone's "commitment" or "promise". Kernel maintainers was to have very good control over the kernel and they want strong separation of concern. As long as this is not delivered, it will be very hard to accept the Rust changes.

As a non-interested observer; I think it will need to be said until the commitment becomes credible. I don't know how it would become credible, but it's clearly not considered credible by at least those of the kernel maintainers who are worried about the maintenance burden of accepting rust patches.

That doesn't line with https://rust-for-linux.com/rust-kernel-policy#who-is-respons... (which may be a recent change?)

I don't think it is this simple.

> the Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side.

How have they "committed"? By saying they commit[1], I presume -- but what more? Anyone can say anything. I think what makes the "old guard" kernel maintainers nervous is the lack of a track record.

And yes, I know that's a kind of a lifting-yourself-by-your-bootstraps problem. And no, I don't know of any solution to that. But I do know that, like baron Münchhausen, you can't ride your high horse around the swamp before you've pulled your self out of it.

___

[1]: And, as others in this thread have shown, that's apparently just out of one side of their collective mouth: The official "Rust kernel policy" says otherwise.

> 99% of insufferable Rust vs. C interactions I've come across it was the C fella being the asshole. So sorry, but no, not very convincing or "totally reasonable" at all.

This has also been my observation as a C++ developer who finds themselves in a fair few C/C++-aligned spaces. There are exceptions, but in most of those spaces the amount of Rust Derangement Syndrome I've witnessed is honestly kind of tiresome at this point.

I can't believe you're the first person I find in this conversation who raises this issue. This is the exact reason why Marcan flipped his lid. Linus publicly championed a very technically complex initiative and then left all those contributors to the wolves when things didn't progress without a hiccup. Especially damning when you consider that at every step, the fief lords in Linux have seemingly done everything in their power to set up the r4l people for failure and Linus hasn't so much as squeaked at them. He personally cut the knot and asserted that Rust is Linux's future, but he constantly allows those below him to relitigate the issue with new contributors (who can't fight back because even though they're contributing by the supposed rules, they don't have enough social buy-in).

> my contributions to a project had been sabotaged

I really wish people would stop throwing around the word "sabotaged". No one "sabotaged" anything. The opposition has been public from the beginning.

If I'm opposed to something, and someone asks my opinion about it in a private conversation, it is not "sabotage" to express my opinion. So far I haven't seen any evidence that those opposed to a mixed-language code base organized behind the scenes to hamper progress in anyway. Instead, their opposition has been public and in most cases instant.

Are people not allowed to be opposed to things anymore?

[flagged]