[diragon]

Rust in Linux has a known constantly showing negative consequence: it introduces another language to the stack. Furthermore, Rust is quite different from C. This makes the whole massively more complicated, and increases the amount of knowledge needed to understand the whole.

The same effect applies every time a new language is introduced, if it doesn't completely replace the previously used language. In this case, Rust won't.

Zig might be a better fit, given how much more similar to C it is.

[capableweb]

> Rust in Linux has a known constantly showing negative consequence

It'd make your argument a lot stronger if you can actually list some of these negative consequences. "Another languages to the stack" and "Different than C" is just complaining about change because it is change.

What negatives have already been shown that isn't just about "This isn't C"?

[rollcat]

Mixing any two languages in any single code base creates significant friction at the boundaries, and adds new degrees of complexity in major areas (build system, tooling, debugging...). If we're talking about a project as complex as a production OS kernel, this kind of a decision should never be taken lightly. It's a much smaller step from 2 to 10 than from 1 to 2.

[cesarb]

> It's a much smaller step from 2 to 10 than from 1 to 2.

But here, you're already starting with 2: C and assembly. Besides inline assembly, a small but very important part of the Linux kernel is written in assembly on every architecture: the system call entry point (entry.S) and the kernel entry point (head.S). And if you consider each architecture's assembly as a separate language, it's more like 10 languages than 2 languages. I'm always impressed whenever I see changes to for instance signal handling or thread flags which touch not only the common code in C, but also the entry point assembly code for each one of the many architectures Linux supports; whoever does these changes need to not only know the assembly language for all these architectures, but also have at hand all the corresponding tooling and emulators to compile and test the changes.

[rollcat]

You do have a point, however (as you noted) the lowest-level bits of an OS kernel are practically impossible to build (and subsequently, maintain) without precise control over the machine code; you can't even start a hobby OS kernel project without relying on assembly. It's a part of the deal; a pure-assembly kernel is more feasible than one without any. You also (as you pointed out) still have to be mindful about the C-asm boundary; the integration doesn't come free.

The story here is pretty different: integrate a new, high-level language into a 30 year old, 30mil SLOC, production code base, that billions of people rely on every day, AND actually extract some value from that work.

[ByTheBook]

A very obvious one is that by adding another language, you are adding more complexity.

It's not as if C is going to disappear from the kernel as it's something like 25 million lines of C code, and if Rust was to be supported, the current C experts who are maintaining various subsystems will now also have to become Rust experts, so that they can effectively accept or reject code contributions in that language.

Personally it just seems illogical, better to make a new kernel in Rust is you really want to use that language, than converting small parts of a HUGE C kernel. Google has been pushing for the inclusion of Rust into the kernel, it's weird that they are not writing their own shiny new Fuchsia OS kernel in Rust, instead of C++.

[xvilka]

Another way is to sponsor and help to develop Redox OS[1] instead. It has a kernel completely written in idiomatic Rust[2].

[1] https://redox-os.org/

[2] https://gitlab.redox-os.org/redox-os/kernel

[dbrrt]

It's funny how frequent people bring this up, but the truth is simple, check here [1]. Zircon kernel is not new [2], it has been in development for a while now. By the time the started to work on the microkernel, Rust 1.0 was really new, so they would've to implement several things from ground up. There's a implementation of Zircon in rust called zCore [3], but I don't know how stable and feature complete this one is.

[1] https://twitter.com/cpugoogle/status/1397265884251525122

[2] Like a two years project.

[3] https://github.com/rcore-os/zCore

[geofft]

Why is it a bad thing that Rust requires you to learn more things? As 'mjg59 pointed out recently, the kernel dev community intentionally asks you to learn more things unrelated to your code as a means of keeping the "bar" high and fielding only committed contributors. Isn't it all the more reasonable to ask people to learn a programming language? https://twitter.com/mjg59/status/1413406419856945153

Rust isn't terribly hard to learn, especially for a kernel developer with a good understanding of C and of memory. You can pick up the basics in probably an hour. A lot of its design choices match approaches the kernel already takes (traits are like ops structs, errors are reported via return values, etc.)

And Rust is a language that plenty of college students pick up for fun. Professional kernel engineers should be able to learn it just fine. Frankly the hardest thing about Rust is that it makes you think deeply about memory allocation, concurrent access across threads, resource lifetimes, etc. - but these are all things you have to think deeply about anyway to write correct kernel code. If you have a good model for these things in C, you can write the corresponding Rust quickly.

In fact, learning Rust and thinking about Rust's concurrency rules has made RCU a lot easier for me to understand. RCU is famously a difficult concept, but the kernel uses it extensively and expects people to use it. So "requires little knowledge and is easy to understand" is not an existing design goal of the kernel - but having people pick up Rust might help there anyway.

(Zig seems like an entirely reasonable choice too. Send in some patches! :) )

[scoutt]

> Rust isn't terribly hard to learn, especially for a kernel developer with a good understanding of C and of memory.

I'm not so sure. I program in C for a living (embedded, for almost 20 years) and believe me that I tried learning Rust, but when I see something like:

    _dev: Pin<Box<Registration<Ref<Semaphore>>>>

I cannot even image the knowledge code like that might require, its implication, the result, the reason why it was written like that. It's confuse. It's seems like something a trying to workaround a language limitation. Not nice at all.

Source: https://github.com/Rust-for-Linux/linux/blob/rust/samples/ru...

[moltonel3x]

Adding Rust complicates things, but Rust makes writing correct code easier, which is no small feat in the kernel world. The added complexity may be big, but it's a one-time cost compared to the stream of Rust code that one can hope for.

Rust is known to be hard to learn (YMMV), but C is even harder. If things go according to plan, someday for some use-cases you'll be able to contribute kernel code in pure safe Rust without having to learn C. In the meantime, adding Rust doesn't seem to be such a big ask when you consider what the kernel already has beside C: Assembler, the "C preprocessor (yes, it's actually a different language independent from C, and some kernel macros are really complicated), the BPF an io_uring APIs (essentially their own DSL), and a myriad of other inner-platform curiosities you might need to deal with depending on the kind of kernel work you do.

Concerning Zig, the cons may be smaller then Rust, but so are the pros. IMHO it's not worth it in the current context (I like Zig but it seems "too little, too late" to me). But there's no telling until somebody puts in the work for a "$OTHER_LANGUAGE in the kernel" RFC like is currently happening for Rust.

[pjmlp]

Zig's syntax has nothing to do C, and overdoes it with @ everywhere.

Until it fixes use-after-free, better keep using C anyway.

[_vvhw]

What Zig shares with C is orthogonality, with a large power-to-weight ratio, meaning it's a small language grammar with powerful range.

But Zig also improves on C's safety in many ways, not least checked arithmetic enabled by default in safe release modes, along with bounds checked memory accesses, function return values that cannot be ignored, checked syscall error handling, explicit allocations, comptime over macros, a short learning curve and remarkable readability.

It's hard for systems programmers not to appreciate any of these qualities in isolation.

[pjmlp]

A brilliant language wouldn't stuffer from use-after-free in 2021, or use file import as module concept.

[diragon]

Syntax is almost completely irrelevant.

[pjmlp]

If syntax was irrelevant, ALGOL like systems programming languages would still dominate.

[diragon]

Not Lisp?

[pjmlp]

Lisp failure in mainstream market is more related to mismanagement, cheap UNIX workstations and AI Winter, than syntax.

But hey, its spirit lives on most managed languages, Julia, Closure, WebAssembly text files and plenty of other stuff Lisp based.

[bitwize]

We, the global community of software developers, are in the process of putting C out to pasture, with Rust as the de facto front runner as a successor. At this point it becomes a question of either admitting Rust into the kernel or, eventually, using another kernel written in Rust.

[moldavi]

The same thing was loudly proclaimed about both C++ and Java, yet C is still here.

[bitwize]

C++ was hampered by the same safety problems C was. And Java had a VM and GC, which cripple performance and determinism. Rust solves both those issues.