Rust in the kernel is no longer experimental

Post by gjajric » Wed, Dec 10, 2025, 9:13 AM UTC

herni wrote: post #174

antioxide wrote: post #165

Earlier quoted context omitted.

you can look at rust sources of real system programs like framekernel or such things. uefi-rs etc. there u can likely explore well the boundaries where rust does and does not work. people have all kind of opinions. mine is this: if you need unsafe peppered around, the only thing rust offers is being very unergonomic. its hard to write and hard to debug for no reason. Writing memory-safe C code is easy. The problems r…

I disagree. Rust shines when you need perform "unsafe" operations. It forces programmers to be explicit and isolate their use of unsafe memory operations. This makes it significantly more feasible to keep track of invariants. It is completely besides the point that you can also write "shit code" in Rust. Just because you are fed up with the "reimplement the world in Rust" culture does not mean that the tool itself is…

Post by pjmlp » Wed, Dec 10, 2025, 9:14 AM UTC

vlovich123 wrote: post #18

drnick1 wrote: post #14

Earlier quoted context omitted.

Every system under the Sun has a C compiler. This isn't remotely true for Rust. Rust is more modern than C, but has it's own issues, among others very slow compilation times. My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.

I can’t think of many real world production systems which don’t have a rust target. Also I’m hopeful the GCC backend for rustc makes some progress and can become an option for the more esoteric ones

Post by johncolanduoni » Wed, Dec 10, 2025, 9:16 AM UTC

vbezhenar wrote: post #92

scuff3d wrote: post #74

Earlier quoted context omitted.

I'm not on the Rust bandwagon, but statements like this make absolutely no sense. A lot of software was written in C and C++ because they were the only option for decades. If you couldn't afford garbage collection and needed direct control of the hardware there wasn't much of a choice. Had their been "safer" alternatives, it's possible those would have been used instead. It's only been in the last few years we've see…

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.

Post by pjmlp » Wed, Dec 10, 2025, 9:17 AM UTC

sho_hn wrote: post #41

mmooss wrote: post #27

Earlier quoted context omitted.

Before we ask if almost all things old will be rewritten in Rust, we should ask if almost all things new are being written in Rust or other memory-safe languages? Obviously not. When will that happen? 15 years? Maybe it's generational: How long before developers 'born' into to memory-safe languages as serious choices will be substantially in charge of software development?

I'm a bit wary if this is hiding an agist sentiment, though. I doubt most Rust developers were 'born into' the language, but instead adopted it on top of existing experience in other languages.

Post by K0nserv » Wed, Dec 10, 2025, 9:21 AM UTC

throw_a_grenade wrote: post #157

jcranmer wrote: post #20

Earlier quoted context omitted.

C currently remains the language of system ABIs, and there remains functionality that C can express that Rust cannot (principally bitfields). Furthermore, in terms of extensions to the language to support more obtuse architecture, Rust has made a couple of decisions that make it hard for some of those architectures to be supported well. For example, Rust has decided that the array index type, the object size type, an…

Also you can't do self-referential strutcs. Double-linked lists are also pain to implement, and they're are heavily used in kernel.