Yep, that's what I'm referring to.

For now there aren't many popular drivers that use Rust, but there are currently 3 in-development GPU drivers that use it, and I suspect that when those get merged that'll be the real point of no return:

- Asahi Linux's driver for Apple GPUs - https://rust-for-linux.com/apple-agx-gpu-driver

- The Nova GPU driver for NVIDIA GPUs - https://rust-for-linux.com/nova-gpu-driver

- The Tyr GPU driver for Arm Mali GPUs - https://rust-for-linux.com/tyr-gpu-driver

I suspect the first one of those to be actually used in production will be the Tyr driver, especially since Google's part of it and they'll probably want to deploy it on Android, but for the desktop (and server!) Linux use-case, the Nova driver is likely to be the major one.

You can force a panic with echo c | /proc/sysrq-trigger

This is so cool! I love things like that, it feels like fresh air after years and years of anachronistic retro-vibes that seem to be a part of C-programming culture.

Arch never failed me. The only time I remember it panicked was when I naively stopped an upgrade in the middle which failed to generate initramfs but quickly fixed it by chroot'ing and running mkinitcpio. Back up in no time

They.

The Unix/C people wrote their own kernel in the 1970s instead of invading an existing one.

He also said in that same email regarding Rust that:

> nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so.

So any argument that Rust would ever fully replace C in such a way that C would go away and be banned in the kernel is NOT what Linus said.

https://lkml.org/lkml/2025/2/20/2066

In-general it seems that Rust proponents want ease and modernity to replace the ability to do the same in C better, with more control and intent, and with better results.

Rust is less tight. That’s fine for an application, but the kernel is used by everyone who uses Linux.

Rustians disparage C because it doesn’t have Rust behavior.

Why must the kernel have Rust behavior?

Is there any evidence "Asahi Lina" is Hector?

Linus Torvalds rips into Hellwig for blocking Rust for Linux:

https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4d...

That was a single message in a very large thread. It absolutely was not just about code quality.

> Looks like Hector has deleted his Mastodon account, so I can't look back what he said exactly.

https://archive.md/uLiWX

https://archive.md/rESxe

https://lkml.org/lkml/2025/2/6/1292

1. He left before Rust stopped being experimental.

2. Maintainers come and go all the time, this is how open source works.

3. The only reason Phoronix reports on this is because anytime they mention Rust it attracts rage bait clicks, for example, your comment.

Then another maintainer will take care of it? This is how kernel development works....

high quality educational material

Ted T'so: "Here’s the thing: you’re not going to force all of us to learn Rust."

https://arstechnica.com/gadgets/2024/09/rust-in-linux-lead-r...

https://youtu.be/WiPp9YEBV0Q?t=1529

linus torvalds

That's a woosh moment

From kernel side, I meant - I wasn't clear. Now I understand what's the meaning of "don't break rust code". Happy that rust's journey in the kernel is successful so far. The pace seems strong.

So does this mean that the C developers might need to learn Rust or cooperate more with the rust developer team basically?

Without a very hard commitment that is going to be a huge hurdle to continued adoption, and kernel work is really the one place where rust has an actual place. Everywhere else you are most likely better off using either Go or Java.

Well, GCC 15 already ended support for the nios2 soft-core. The successor to it is Nios V which runs RISC-V. If users want us update the kernel, they'll also need to update their FPGA.

Microblaze also is a soft-core, based on RISC-V, presumably it could support actual RISC-V if anyone cared.

All others haven't received new hardware within the last 10 years, everybody using these will already be running an LTS kernel on there.

It looks like there really are no reasons not to require rust for new versions of the kernel from now on then!

It’s an interesting list from the perspective of what kind of project Linux is. Things like PA-RISC and Alpha were dead even in the 90s (thanks to the successful Itanium marketing push convincing executives not to invest in their own architectures), and SuperH was only relevant in the 90s due to the Dreamcast pushing volume. That creates an interesting dynamic where Linux as a hobbyist OS has people who want to support those architectures, but Linux as the dominant server and mobile OS doesn’t want to hold back 99.999999+% of the running kernels in the world.

There's Rust for Dreamcast (https://dreamcast.rs) via Rust's GCC backend.

You probably shouldn't include Rust's Tier 3 in this list. If you have to, at least make it separate.

some of the platforms on that list are not supported well enough to say they actually have usable rust, e.g m68k

I've certainly used parisc and alpha, though not for some years now.

> supports 14 of the kernel's 20-ish architectures

That's a lot better than I expected to be honest, I was thinking maybe Rust supported 6-7 architectures in total, but seems Rust already has pretty wide support. If you start considering all tiers, the scope of support seems enormous: https://doc.rust-lang.org/nightly/rustc/platform-support.htm...

Its strange to me that Linux dropped Itanium two years ago but they decided to keep supporting Alpha and PA-RISC.

m68k Linux is supported by Rust, even in the LLVM backend.

Rust also has an experimental GCC-based codegen backend (based on libgccjit (which isn't used as a JIT)).

So platforms that don't have either LLVM nor recent GCC are screwed.

Well - what is actually written in Rust so far that is in the kernel?

Isn't that ultimately a loss of motivation? With enough buy in there would be a lot of reason to keep iterating towards the desired outcome despite any setbacks. That is the nature of experiments, after all. Things going horribly wrong while you are in the iteration process is an expected part of experimentation.

Imagine a world where the Rust experiment hand't been going well. There is absolutely nothing stopping someone from keeping at it to prove why Rust should be there. The experiment can always live as long as someone wants to keep working on it. Experiments fundamentally can only end when successful, or when everyone gives up (leaving nobody to make the announcement).

That said, consider me interested to read the announcements HN has about those abandoned experiments. Where should I look to find them?

I don't understand why. Working with hardware you're going to have to do various things with `unsafe`. Interfacing to C (the rest of the kernel) you'll have to be using `unsafe`.

In my mind, the reasoning for rust in this situation seems flawed.

> if the safe wrappers let you write arbitrary data to a PCIe network card’s registers

Functions like that can and should be marked unsafe in rust. The unsafe keyword in rust is used both to say “I want this block to have access to unsafe rust’s power” and to mark a function as being only callable from an unsafe context. This sounds like a perfect use for the latter.

In normal user-mode rust, not running inside the kernel at all, you can open /dev/mem and write whatever you want to any process's memory (assuming you are root). This does not require "unsafe" at all.

Another thing you can do from rust without "unsafe": output some buggy source code that invokes UB in a language like C to a file, then shell out to the compiler to compile that file and run it.

> There are crucial issues, namely that there is no spec and there is only one implementation. I don't know why Linus is ok with this.

I can try to provide a (weak) steelman argument:

Strictly speaking, neither the lack of a spec nor a single implementation have been blockers for Linux's use of stuff, either now or in the past. Non-standard GCC extensions and flags aren't exactly rare in the kernel, and Linus has been perfectly fine with the single non-standard implementation of those. Linus has also stated in the past (paraphrasing) that what works in practice is more important than what standards dictate [0]. Perhaps Linus feels that what Rust does in practice is good enough, especially given its (currently) limited role in the kernel.

Granted, not having a spec for individual flags/features is not equivalent to not having a spec for the language, so it's not the strongest argument as I said. I do think there's a point nestled in there though - perhaps what happens on the ground is the most important factor. It probably helps that there is work being done on both the spec and multiple implementation fronts.

[0]: https://lkml.org/lkml/2018/6/5/769

Yeah they’re all just tools. From a technical perspective, rust, C and C++ work together pretty well. Swift too. LLVM LTO can even do cross language inlining.

I don’t think C++ is going anywhere any time soon. Not with it powering all the large game engines, llvm, 30 million lines of google chrome and so on. It’s an absolute workhorse.

I would like a revision to bitfields and structs to make them behave the way a programmer things, with the compiler free to suggest changes which optimize the layout. As well as some flag that indicates the compiler should not, it's a finalized structure.

Now, try and use two or more libraries that expose data structures with bitfields, and they have all chosen different crates for this (or even the same crate but different, non-ABI-compatible-versions of it).

There's a ton of standardization work that really should be done before these are safe for library APIs. Mostly fine to just write an application that uses one of these crates though.

Yeah, not sure what they're saying... I use bitfields in multiple of my rust projects using those macros.

There is a cost to having multiple language-level types that represent the exact same set of values, as C has (and is really noticeable in C++). Rust made an early, fairly explicit decision that a) usize is a distinct fundamental type from the other types, and not merely a target-specific typedef, and b) not to introduce more types for things like uindex or uaddr or uptr, which are the same as usize on nearly every platform.

Rust worded in its initial guarantee that usize was sufficient to roundtrip a pointer (making it effectively uptr), and there remains concern among several of the maintainers about breaking that guarantee, despite the fact that people on the only target that would be affected basically saying they'd rather see that guarantee broken. Sort of the more fundamental problem is that many crates are perfectly happy opting out of compiling for weirder platform--I've designed some stuff that relies on 64-bit system properties, and I'd rather like to have the ability to say "no compile for you on platform where usize-is-not-u64" and get impl From<usize> for u64 and impl From<u64> for usize. If you've got something like that, it also provides a neat way to say "I don't want to opt out of [or into] compiling for usize≠uptr" and keeping backwards compatibility.

If you want to see some long, gory debates on the topic, https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-... is a good starting point.

> Is it something that can be fixed with editions? My guess is no, or at least not easily.

Assuming I'm reading these blog posts [0, 1] correctly, it seems that the size_of::<usize>() == size_of::<*mut u8>() assumption is changeable across editions.

Or at the very least, if that change (or a similarly workable one) isn't possible, both blog posts do a pretty good job of pointedly not saying so.

[0]: https://faultlore.com/blah/fix-rust-pointers/#redefining-usi...

[1]: https://tratt.net/laurie/blog/2022/making_rust_a_better_fit_...

> Rust has native SIMD support

std::simd is nightly only.

> while in standard C there is no way to express that.

In ISO Standard C(++) there's no SIMD.

But in practice C vector extensions are available in Clang and GCC which are very similar to Rust std::simd (can use normal arithmetic operations).

Unless you're talking about CPU specific intrinsics, which are available to in both languages (core::arch intrinsics vs. xmmintrin.h) in all big compilers.

AFAIK std::simd is still nightly only. You can use the raw intrinsics in std::arch, but that's not any better than "#include <immintrin.h>".

So use the fairly common SIMD extensions in C, that's not much of an argument.

CHERI has 64-bit object size but 128-bit pointers (because the pointer values also carry pointer provenance metadata in addition to an address). I know some of the pointer types on GPUs (e.g., texture pointers) also have wildly different sizes for the address size versus the pointer size. Far pointers on segmented i386 would be 16-bit object and index size but 32-bit address and pointer size.

There was one accelerator architecture we were working that discussed making the entire datapath be 32-bit (taking less space) and having a 32-bit index type with a 64-bit pointer size, but this was eventually rejected as too hard to get working.

> Also you can't do self-referential strutcs.

You mean in safe rust? You can definitely do self-referential structs with unsafe and Pin to make a safe API. Heck every future generated by the compiler relies on this.

[flagged]

We're already at the point where in order to have a "decent" desktop software experience you _need_ Rust too. For instance, Rust doesn't support some niche architectures because LLVM doesn't support them (those architectures are now exceedingly rare) and this means no Firefox for instance.

Java hasn't ever been essential outside enterprise-y servers and those don't care about "any viable system".

A system only needs one programming language to be useful, and when there's only one it's basically always C.

> There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash

Java, really? I don’t think Java has been essential for a long time.

Is Perl still critical?

> Rust I don't think has made it through that door yet, but on current trends, it's at the threshold and will almost certainly step through.

I suspect what we are going to see isn't so much Rust making it through that door, but LLVM. Rust and friends will come along for the ride.

Removing Java from my desktop Arch system only prompts to remove two gui apps I barely use. I could do it right now and not notice for months.

Even Perl... It's not in POSIX (I'm fairly sure) and I can't imagine there is some critical utility written in Perl that can't be rewritten in Python or something else (and probably already has been).

As much as I like Java, Java is also not critical for OS utilities. Bash shouldn't be, per se, but a lot of scripts are actually Bash scripts, not POSIX shell scripts and there usually isn't much appetite for rewriting them.

Debian and Ubuntu enter the chat.....

I don't think Perl comes pre installed on any modern system anymore

I wouldn't be surprised to see zig in the kernel at some point

There aren't really any "systems programming" platforms anywhere near production that doesn't have a workable rust target.

It's "embedded programming" where you often start to run into weird platforms (or sub-platforms) that only have a c compiler, or the rust compiler that does exist is somewhat borderline. We are sometimes talking about devices which don't even have a gcc port (or the port is based on a very old version of gcc). Which is a shame, because IMO, rust actually excels as an embedded programming language.

Linux is a bit marginal, as it crosses the boundary and is often used as a kernel for embedded devices (especially ones that need to do networking). The 68k people have been hit quite hard by this, linux on 68k is still a semi-common usecase, and while there is a prototype rust back end, it's still not production ready.

It's mostly embedded / microcontroller stuff. Things that you would use something like SDCC or a vendor toolchain for. Things like the 8051, stm8, PIC or oddball things like the 4 cent Padauk micros everyone was raving about a few years ago. 8051 especially still seems to come up from time to time in things like the ch554 usb controller, or some NRF 2.4ghz wireless chips.

Commercial embedded OSes, game consoles, for example.

Though to be fair, POSIX is increasingly outdated.

Compared to C, rust compiles much slower. This might not matter on performant systems, but when resources are constrained you definitely notice it. And if the whole world is rewritten in Rust, this will have a non-significant impact on the total build time of a bunch of projects.

typescript transpilation to js is nearly instant, it's not comparable

Sure, but the reason tends to be that if you want something to run everywhere, C is your best bet.

rustc can use a few different backends. By my understanding, the LLVM backend is fully supported, the Cranelift backend is either fully supported or nearly so, and there's a GCC backend in the works. In addition, there's a separate project to create an independent Rust frontend as part of GCC.

Even then, there are still some systems that will support C but won't support Rust any time soon. Systems with old compilers/compiler forks, systems with unusual data types which violate Rust's assumptions (like 8 bit bytes IIRC)

There are a number of oddball platforms LLVM doesn't support, yeah.

Many organizations and environments will not switch themselves to LLVM to hamfist compiled Rust code. Nor is the fact of LLVM supporting something in principle means that it's installed on the relevant OS distribution.

The reason you rarely hear that mentioned is because basically every programming language is hard to work with from other languages. The usual solution is to "just" expose a C API/ABI.

Of course, C API/ABIs aren't able to make full use of Rust features, but again, that also applies to basically every other language.

Perhaps we can finally stop defining abis in terms of c structs!

I think you didn't catch their drift

C will continue to be used because it always has been and always will be available everywhere, not only places no one uses :/

You almost certainly have a bunch of devices containing a microcontroller that runs an architecture not targeted by LLVM. The embedded space is still incredibly fragmented.

That said, only a handful of those architectures are actually so weird that they would be hard to write a LLVM backend for. I understand why the project hasn’t established a stable backend plugin API, but it would help support these ancillary architectures that nobody wants to have to actively maintain as part of the LLVM project. Right now, you usually need to use a fork of the whole LLVM project when using experimental backends.

> many devs keep ignoring

And thats why Zig don’t offer much. Devs will just ignore it.

Can you elaborate, what key assumptions about memory safety linked lists break? Sure, double linked lists may have non-trivial ownership, but that doesn't compromise safety.

Yeah, if you need a linked list (you probably don't) use that. If however you are one of the very small number of people who need fine-grained control over a tailored data-structure with internal cross-references or whatnot then you may find yourself in a world where Rust really does not believe that you know what you are doing and fights you every step of the way. If you actually do know what you are doing, then Zig is probably the best modern choice. The TigerBeetle people chose Zig for these reasons, various resources on the net explain their motivations.

I think that misses the point though. C trusts you to design your own linked list.

It also trusts your neighbor, your kid, your LLM, you, your dog, another linked list...

A container class that needs cooperation from the contained items, usually with special data fields. For example, a doubly linked list where the forward and back pointers are regular member variables of the contained items. Intrusive containers can avoid memory allocations (which can be a correctness issue in a kernel) and go well with C's lack of built-in container classes. They are somewhat common in C and very rare in C++ and Rust.

A data structure that requires you to change the data to use it.

Like a linked list that forces you to add a next pointer to the record you want to store in it.

People can learn Rust at any age. The reality is that experienced people often are more hesitant to learn new things.

I can think of possible reasons: Early in life, in school and early career, much of what you work on is inevitably new to you, and also authorities (professor, boss) compel you to learn whatever they choose. You become accustomed to and skilled at adapting new things. Later, when you have power to make the choice, you are less likely to make yourself change (and more likely to make the junior people change, when there's a trade-off). Power corrupts, even on that small scale.

There's also a good argument for being stubborn and jaded: You have 30 years perfecting the skills, tools, efficiencies, etc. of C++. For the new project, even if C++ isn't as good a fit as Rust, are you going to be more efficient using Rust? How about in a year? Two years? ... It might not be worth learning Rust at all; ROI might be higher continuing to invest in additional elite C++ skills. Certainly that has more appeal to someone who knows C++ intimately - continue to refine this beautiful machine, or bang your head against the wall?

For someone without that investment, Rust might have higher ROI; that's fine, let them learn it. We still need C++ developers. Morbid but true, to a degree: 'Progress happens one funeral at a time.'

Sure there are plenty of them, hence why you seem remarks like wanting to use Rust but with a GC, or assigned to Rust features that most ML derived languages have.

New high-scale data infrastructure projects I am aware of mostly seem to be C++ (often C++20). A bit of Rust, which I’ve used, and Zig but most of the hardcore stuff is still done in C++ and will be for the foreseeable future.

It is easy to forget that the state-of-the-art implementations of a lot of systems software is not open source. They don’t struggle to attract contributors because of language choices, being on the bleeding edge of computer science is selling point enough.

Game development, graphics and VFX industry, AI tooling infrastructure, embedded development, Maker tools like Arduino and ESP32, compiler development.

https://github.com/tigerbeetle/tigerbeetle

Out of curiosity, do the LLMs all use memory safe languages?

I prefer a billion dallars tax free, but here we are:(

Do you also want some unicorns as well?

[dead]

Afaik despite Rust not having exceptions, panic still unwinds the stack and executes 'drop'-s the same way C++ does, which means the code retains much of the machinery necessary to support exceptions.

Not trying to make a value judgement on Rust either, just brainstorming why Rust changeover might go slow per the question.

FWIW I work in firmware with the heap turned off. I’ve worked on projects in both C and Rust, and agree Rust still adds useful checks (at the cost of compile times and binary sizes). It seems worth the trade off for most projects.

I'm curious why your perspective on Rust as a HW engineer. Hardware does a ton of things - DMA, interrupts, etc. that are not really compatible with Rust's memory model - after all Rust's immutable borrows should guarantee the values you are reading are not aliased by writers and should be staying constant as long as the borrow exists.

This is obviously not true when the CPU can either yank away the execution to a different part of the program, or some foreign entity can overwrite your memory.

Additionally, in low-level embedded systems, the existence of malloc is not a given, yet Rust seems to assume you can dynamically allocate memory with a stateless allocator.

So you try to say c is for good programmers only and rust let also the idiots Programm? I think that’s the wrong way to argue for rust. Rust catches one kind of common problem but but does not magically make logic errors away.

Swift does not seem suitable for OS development, at least not as much as C or C++.[0] Swift handles by default a lot of memory by using reference counting, as I understand it, which is not always suitable for OS development.

[0]: Rust, while no longer officially experimental in the Linux kernel, does not yet have major OSs written purely in it.

But you now have more complexity and no extra safety.

[flagged]

I don’t agree that C++ is a bad language, though it has been standardized to death into a bad language. But the whole point is for C++ to not be worse than C while offering a lot more, which I think it does well. Of course, my last serious use of C++ was a little after release E…

The Temporal API in Chrome is implemented in Rust. We’re definitely seeing more Rust in browsers including beyond Firefox.

Unless rules have changed Rust is only allowed a minor role in Chrome.

> Based on our research, we landed on two outcomes for Chromium.

> We will support interop in only a single direction, from C++ to Rust, for now. Chromium is written in C++, and the majority of stack frames are in C++ code, right from main() until exit(), which is why we chose this direction. By limiting interop to a single direction, we control the shape of the dependency tree. Rust can not depend on C++ so it cannot know about C++ types and functions, except through dependency injection. In this way, Rust can not land in arbitrary C++ code, only in functions passed through the API from C++.

> We will only support third-party libraries for now. Third-party libraries are written as standalone components, they don’t hold implicit knowledge about the implementation of Chromium. This means they have APIs that are simpler and focused on their single task. Or, put another way, they typically have a narrow interface, without complex pointer graphs and shared ownership. We will be reviewing libraries that we bring in for C++ use to ensure they fit this expectation.

-- https://security.googleblog.com/2023/01/supporting-use-of-ru...

Also even though Rust would be a safer alternative to using C and C++ on the Android NDK, that isn't part of the roadmap, nor the Android team provides any support to those that go down that route. They only see Rust for Android internals, not app developers

If anything, they seem more likely to eventually support Kotlin Native for such cases than Rust.

In robotics too.

> Memory safety applies to all memory. Not just heap allocated memory.

> Anyway, Rust has benefits beyond memory safety.

I want to elaborate on this a little bit. Rust uses some basic patterns to ensure memory safety. They are 1. RAII, 2. the move semantics, and 3. the borrow validation semantics.

This combination however, is useful for compile-time-verified management of any 'resource', not just heap memory. Think of 'resources' as something unique and useful, that you acquire when you need it and release/free it when you're done.

For regular applications, it can be heap memory allocations, file handles, sockets, resource locks, remote session objects, TCP connections, etc. For OS and embedded systems, that could be a device buffer, bus ownership, config objects, etc.

> > Nearly all of the relevant code is unsafe. There aren't many real benefits.

Yes. This part is a bit weird. The fundamental idea of 'unsafe' is to limit the scope of unsafe operations to as few lines as possible (The same concept can be expressed in different ways. So don't get offended if it doesn't match what you've heard earlier exactly.) Parts that go inside these unsafe blocks are surprisingly small in practice. An entire kernel isn't all unsafe by any measure.

The “Ouch.” was in reference to being compared to Phoronix.

Has anyone found them to be inaccurate, or fluffy to the point it degraded the content?

I haven’t - but then again, probably predominantly reading the best posts being shared on aggregators.

This one is apparently a genuine mistake from the author. But I think we should leave it as it is. The confusion and the argument about it is interesting in itself.

This should just be the pinned comment.

The kind of Rust you would use in the kernel is no more high-level than C is.

> Forget the bells-and-whistles and answer this: does the use of Rust generate a result that is more performant and more efficient than the best result using C?

These are the performance results for an NVMe driver written in Rust: https://rust-for-linux.com/nvme-driver

It's absolutely on par with C code.

At least on PC world you could be using Delphi, for example, or Turbo Pascal before it.

Also I would refrain me to list all other alternatives.

One could rewrite curl with Perl 30 years ago. Or with Java, Golang, Python, you name it. Yet it stays written with C even today.

you took the ragebait bro :))

As everybody knows not a single programming language was released between C++ and Rust.

OS kernels? Everything from numpy to CUDA to NCCL is using C/C++ (doing all the behind the scene heavy lifting), never mind the classic systems software like web browsers, web servers, networking control plane (the list goes on).

They're easier because, amongst other improvements, they are safer.

And when they were mandated, it made a lot of people very angry!

https://www.cbc.ca/player/play/video/1.3649589

You can write slop in any language. And good software for that matter.

Agreed, the vagueposting is indication of ill-intent of the top-level comment. No hyperlinks or specifics, it might as well be a game of mad-libs where you insert your grievance here.

I don't know that there's a list, but cases come to mind because they've been controversial.

(Not a Linux hacker, so apologies if I get this wrong)

The filesystem APIs were quite arcane, and in particular whether or not you were allowed to call a C function at a certain point wasn't documented, and relied on experience to know already.

In trying to write idiomatic Rust bindings, the Rust for Linux group asked the filesystems maintainer if they could document these requirements, so that the Rust bindings could enforce as much of them as they could.

The result was... drama.

I totally hear you about C friendly APIs not making sense in rust. GTK struggles with this - I tried to make a native UI in rust a few months ago using gtk and it was horrible.

> Also, a more Rust-friendly model would have incured higher memory costs.

Can you give some details? This hasn’t been my experience.

I find in general rust’s ownership model pushes me toward designs where all my structs are in a strict tree, which is very efficient in memory since everything is packed in memory. In comparison, most C++ APIs I’ve used make a nest of objects with pointers going everywhere. And this style is less memory efficient, and less performant because of page faults.

C has access to a couple tricks safe rust is missing. But on the flip side, C’s lack of generics means lots of programs roll their own hash tables, array lists and various other tools. And they’re often either dynamically typed (and horribly inefficient as a result) or they do macro tricks with type parameters - and that’s ugly as sin. A lack of generics and monomorphization means C programs usually have slightly smaller binaries. But they often don’t run as fast. That’s often a bad trade on modern computers.

This is ultimately a good example of how to use Rust. You express as much of the API as you can safely, and the rest is unsafe. APIs that can't be safely modelled can still be exposed to Rust & marked unsafe, if they're needed

Which SDK? I've only written Rust FFI to pretty basic C APIs. I'm curious to get a sense of the limitations on something more complex

How is that relevant to discussion about complexity?

Kernel doesn't use Cargo.

> You don't generally need specific versions of GCC or Clang to build it I'm pretty sure.

You need a C11 compiler these days with loads of non-standard extensions. Note, for a very long time, one couldn't compile the Linux kernel with clang because it lacked this GCC specific behavior.

I'm not really sure you can turn around and say -- Oh, but now we feel differently about the C standard -- given how much is still non-standard. For instance, I don't believe Intel's C compiler will compile the kernel, etc.

The Linux kernel has been using stable versions of Rust for some time now. You do not need nightly or beta Rust compilers to compile the kernel.

https://www.phoronix.com/news/Linux-Patches-Multiple-Rust-Ve...

> It's about the constant drama.

So why are you posting things like drama queen:

> I guess it's time to finally try FreeBSD.

(btw. FreeBSD is fine)

Not sure if this is speech to text.

Ah! I hadn't considered that, thanks. That makes way more sense - having read the article I couldn't figure out what was being said here otherwise.

Linus holds many opinions chiefly based on 90's experience, many not relevant any more. So it goes.

>"My understanding is the primary reason Linus gave Tanenbaum for the monolithic design was performance, but I would think in 2025 this isn’t so relevant anymore."

I think that unlike user level software performance of a kernel is of utmost importance.

Why do you think performance isn't relevant in 2025?

Not sure I get the joke. MINIX is not building from scratch. It's a serious choice if one needs a microkernel. Hurd is more experimental but still not Amish.

> That's not the case. It's using Rust as a selling point

"Rust as a selling point" was a big thing in 2018-2022ish. You see it a lot less of the "written in Rust" in HN headlines these days. Some people were very excited about Rust early on. What feels more common today are people who unnecessarily hate Rust because they saw too much of this hype and they (justifiably) got annoyed by it.

If there is a new, optional language to be added to Linux Kernel development, Rust makes sense. It's a low level, performant, and safe language. Introducing it for driver development has almost no impact on 99% of users, except maybe it'll safe them a memory related bug fix patch having to be installed at some point. Is Rust the "selling point" here, or is the potential to avoid an entire class of bugs the selling point?

> The fact that you think linux machines are enjoyed by only a specific group of people makes me happier with my choice

If by "specific group of people" you mean "people who will refuse to use an OS based on the implementation language(s)", then I guess so.

I don't mean to be rude (although it reads like it, apologies), but I just think that you're coming at this from a perspective of malice instead of what the goal was, which was to reduce bugs in kernel drivers, and not to pimp Rust as a programming language by getting it into a large software project.

> It's using Rust as a selling point.

That's just not true. Neither Linus Torvalds, nor the Linux Foundation, nor any major distro, nor anyone else who could conceivably be considered responsible for "marketing" Linux is saying you should use it because a small part of it is written in Rust.

I just went to ubuntu.com and the word "rust" does not appear anywhere on the front page. So what are you talking about?