Comment by andrewstuart

That's a false equivalency. All of those languages are integrated through strong semantic and concrete abstractions (e.g. file system I/O or GCC interfaces) that evolve, if at all, very slowly. Some, like assembly, are necessary concessions, and are exceptions that prove the rule--developers prefer GCC builtins if available, for example.

The problem with Rust in the kernel is that the kernel has historically eschewed strong internal abstractions. The Linux kernel has no principled abstract architecture in the same way that Windows NT does; it has evolved very organically and even some of the most foundational subsystem APIs regularly see refactorings that touch almost every corner of the kernel.

The latest dispute (if it could be called that) regarding Rust was Rust building abstractions around the DMA interface. There's nothing wrong with this, per se. For Rust it's a necessary chore. But when you build complex abstractions atop something, you're either ossifying the interface or building a sand castle. If we're being charitable, some Linux developers felt like this was pressure to ossify the existing abstractions. Rust developers, OTOH, promised that they'd take full responsibility for any future refactoring, implicitly admitting that they understood they were building a sand castle.

How do you bridge that divide? Because of the lack of hard architectural line drawing in how Linux is developed, the norm is that both redesigns and refactoring are in many respects highly cooperative (notwithstanding the bickering and friction). A subsystem maintainer contemplating a redesign takes into consideration the burdens on other users, and how a redesign might be incrementally rolled out, if at all. Conversely, users of interfaces know--or should know--to take into consideration future potential changes in an interface when relying on an interface for their subsystems. It's a constant back-and-forth, give-and-take, but also messy and chaotic. Transparency in source code is key--this kind of development would never work in commercial projects across binary interfaces. Yet in important respects that's what the interface between C and Rust is like--opaque--especially when developers on one side aren't intimately familiar with the semantics of the other and how they translate, if at all, across the boundary.

Now here comes Rust, which has spent years putting into place the infrastructure just to get some drivers going. Rust as a language demands careful architecture and line drawing. It's no surprise that much of that initial infrastructure effort, excluding the build, was expended on building towers of abstraction. Refactoring can be painful in Rust when it involves very low-level changes in semantics (the kind that are common in kernel development), and while there are tools to help address that, they don't work well, or at all, outside of Rust. There's a huge impedance mismatch between Rust and historic Linux kernel development. In user land, developers' experience is that Rust is relatively easy to interface with C libraries. But that experience is primarily interfacing with public APIs, those public APIs have always been quite stable, and user land libraries (at least the good ones) are designed to be, as much as possible, blackboxes from the outside. Abstractions that leak tend to be fixed abstractions, like file descriptors, etc, that are typical for the environment and rather predictable.

That situation with user land C FFI is utterly incomparable to how interfaces evolve in Linux. The clash between these worlds, at both a technical and cultural level, was inevitable. Heck, it was evident from day 1. This doesn't make either side right or wrong, and I'm not trying to suggest that the Linux developer community can't figure out a path forward. But it's a difficult problem on many levels.

No, I feel this way about the Linux kernel.