Comment by typ

2 days ago

In my honest opinion, it's not a good idea to mix two programming languages into the same monolithic codebase side by side. It would be less problematic if used for different purposes or layers, like frontend and backend. But we know it still creates unpleasant friction when you have to work on both sides on your own. Otherwise, it creates technical AND communication friction if the C devs and Rust devs work separately. As someone who works with embedded systems at times, I can imagine the pain that you have to set up two toolchains (with vastly different build infra beasts like GNU Make and Cargo) and the prolonged build time of CI and edit-compile-run debugging cycles given the notorious slow compile time of the Rust/LLVM compiler.

25 comments

typ

Reply
dralley  2 days ago

>It would be less problematic if used for different purposes or layers, like frontend and backend.

Good news! At the present moment, Rust is only being used for drivers. Who knows if that will change eventually, but it's already the case that the use case is contained.

cozzyd  2 days ago

Fortunately the rust inside Linux doesn't use cargo and uses the normal kernel build system.

kelnos  2 days ago

Greg K-H's email acknowledges that mixed-language projects are difficult to deal with. But he makes a good mitigating point: they are all Linux kernel maintainers and developers, and they all already work on very hard things. They can handle this.

  • account42  2 days ago

    Sound like hubris. If you are already working at the human limit you definitely don't want to add any additional complexity.

    • astrobe_  1 day ago

      It reminds of the "broken window theory" [1] in the sense that when two windows are broken, breaking a third one seems not to matter (I of course don't suggest that Rust programmers are criminals; I have no proof yet ;-). It is a trap one can easily fall into, e.g. "this method is already huge, adding a couple of lines to it doesn't make a difference".

      [1] https://en.wikipedia.org/wiki/Broken_windows_theory

      1 reply →

saidinesh5  2 days ago

The Rust in kernel doesn't use Cargo, does it? (Genuine question - someone do confirm)

That being said, it depends on how well the two languages integrate with each other - I think.

Some of the best programming experience I had so far was when using Qt C++ with QML for the UI. The separation of concerns was so good, QML was really well suited for what it was designed for - representing the Ui state graph and scripting their interactions etc ... And it had a specific role to fill.

Rust in the kernel - does it have any specific places where it would fit well?

hgs3  2 days ago

> It would be less problematic if used for different purposes or layers, like frontend and backend.

Wouldn't a microkernel architecture shine here? Drivers could, presumably, reside in their own projects and therefore be written in any language: Rust, Zig, Nim, D, whatever.

eviks  2 days ago

> the prolonged build time of CI and edit-compile-run debugging cycles

Does Linux kernel development have hot reload on the C side as a comparison?

  • aaronmdjones  2 days ago

    It used to, until Oracle bought it out. It is not usable for changes to the ABI though; only kernel functions. The use case was hot-patching a running kernel to fix a security vulnerability in e.g. a device driver, but it could be used to modify almost any function.

    https://en.wikipedia.org/wiki/Ksplice