Hacker News Reader

Comment by typ | Hacker News Reader

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.

View on HN

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

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

kbuild just calls cargo under the hood.

No it doesn't. I checked and kbuild calls rustc directly.

The only results for cargo in entire the linux source tree is documentation suggesting you install bindgen via cargo install.... Plus a bunch of comments referencing "cargo-cult programming"

You checked with grep or something more?

https://github.com/search?q=repo%3Atorvalds%2Flinux%20cargo&...

And you can see under samples/rust that only a kbuild-style Makefile is provided: https://github.com/torvalds/linux/tree/master/samples/rust

not enough reading

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.

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

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

You are right, but this is being hedged against the advantages of adding Rust. I daresay no one would agree to more work for no perceived benefit. If you want to contest this tradeoff, that's a different tack.

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?

Yes, cargo is involved. R4L currently works by invoking kbuild to determine the CFLAGS, then passes them to bindgen to generate the rust kernel bindings. It then invokes cargo under the hood, which uses the bindings and the crate to generate a static lib that the rest of the kernel build system can deal with.

no? there's only a single mention of cargo in the entire kernel, and it's in a docs page describing how to install bindgen, a toolchain dependency of the kernel, below a whole list of other non-cargo ways to install bindgen.

https://github.com/search?q=repo%3Atorvalds%2Flinux%20cargo&...

I’m right with you! Qt C++ with QML is the absolute best combo for programming GUI apps. I wrote about it on my blog post[1].

[1] https://rubymamistvalove.com/block-editor

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

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

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

I can imagine a possible future of 100% Rust takeover of the kernel.

It doesn't even need to be 100% rust to gain most rust benefits.

Just by forcing new features to be written in rust, it will decrease potential memory safety related bugs / vulnerabilities drastically

https://security.googleblog.com/2024/09/eliminating-memory-s...

Sure it's hard. But the security rewards are worth it.

the kernel should use bazel /s?

Reply on news.ycombinator.com