Torvalds: You can avoid Rust as a C maintainer, but you can't interfere with it

Policy “middle ground” and kernel governance

• Many see Torvalds’ stance as a pragmatic compromise: C maintainers don’t have to learn or review Rust, but also can’t veto Rust users of their APIs.
• Some argue calling this “middle ground” overstates it; they view it as simple common sense that API users can be in any language.
• Key clarification from several commenters: the disputed Rust DMA patches did not modify the C DMA layer at all; they were just new Rust users of an existing API.

C vs Rust in low‑level and embedded work

• Ongoing debate whether C has a permanent niche “closest to the metal” (bit‑banging, exotic hardware, very predictable codegen) or whether Rust/C++ can fully cover that space.
• Some embedded developers report Rust can do everything they did in C, but tooling and ecosystem are less mature.
• Others argue C’s predictability is overrated: UB and aggressive optimizers already make assembly output non‑obvious; for truly strict control you need inline asm regardless of language.

APIs, maintainers, and cross‑language boundaries

• One camp: maintainers should care only that their C API contract is correct and documented; how it’s used (language, use case) is not their business.
• Another camp: if Rust becomes a major or primary consumer of an API, ignoring Rust usage “as a policy” harms quality; at minimum, maintainers should show interest in how their APIs are consumed.
• Several note you can’t give meaningful feedback on Rust bindings without knowing Rust; thus the burden should sit with Rust maintainers to adapt to C APIs.

Multi‑language codebases and “golden rule” debate

• One view: “golden rule” is to minimize languages in a project to avoid silos and hiring/training pain; examples given of Scala/Java and Kotlin/React Native splits causing ownership chaos.
• Counterview: almost nobody works in single‑language backends; mixing C/Go/Python/SQL/etc. is normal and manageable if roles and boundaries are clear.
• Consensus tendency: adding a new language should be justified by clear benefits, but it’s not inherently pathological.

Culture, communication, and Torvalds’ style

• Several note Torvalds still gives very blunt feedback, but with somewhat softer phrasing than in the past; some think this firmness is necessary to keep kernel quality high.
• Others criticize past emails as personally harsh rather than merely “direct,” debating whether this is cultural (non‑Anglo directness) or simply unacceptable behavior.

Forking, freedom, and project identity

• A minority argues Rust advocates should fork a Rust‑heavy kernel instead of “imposing” Rust on C maintainers, invoking “freedom” in free software.
• Others respond that Rust developers are already part of the maintainer body, and that forking would squander scarce manpower; Linux itself wasn’t a Unix fork but an independent OS.
• Some predict no serious C‑only fork: most major contributors are paid by companies unlikely to back a split.

Tooling, build, and process

• Rust is already in parts of the kernel, so toolchain and build implications are seen as largely unchanged by this specific dispute.
• Mailing lists remain criticized as hard to read and participate in, despite being described (tongue‑in‑cheek) as part of a “well‑oiled engineering marvel.”