Rust in the kernel is no longer experimental • Hacker News Board

Re: Rust in the kernel is no longer experimental

#791

Post by dzaima » Thu, Dec 11, 2025, 9:07 AM UTC

eru wrote: post #752

dzaima wrote: post #342

Earlier quoted context omitted.

Storing the data in nodes doesn't work if the given structure may need to be in multiple linked lists, which iirc was a concern for the kernel? And generally I'd imagine it's quite a weird form for data structures for which being in a linked list isn't a core aspect (no clue what specifically the kernel uses, but I could imagine situations where where objects aren't in any linked list for 99% of time, but must be abl…

> Storing the data in nodes doesn't work if the given structure may need to be in multiple linked lists, which iirc was a concern for the kernel? That's a great point! A language almost like C plus a smart enough compiler could do the unboxing, but this technique doesn't work for multiple structures. > And generally I'd imagine it's quite a weird form for data structures for which being in a linked list isn't a core…

> you just need to make sure that the system keeps a big enough buffer of contiguous-enough space somewhere. Similar to how many filesystems allow you to reserve space for root

Said file system reserving can fill up (I've experienced that :) ). Could perhaps engineer some super-equation for a global reserved memory size that can actually guarantee being sufficient; but, unless you mark allocations as needing reserved space vs not and compute based on that (which is back to overhead), that'll necessarily waste a good amount of memory.

And such a global equation of course can result in global failure if just one subsystem miscalculates its required reserved amount, or the calculations improperly account for worst-case non-contiguousness or interleaved different-size-linked-list-alloc-requests or whatever. (never mind that you now need to alloc when adding elements to linked lists, an action that would otherwise be 1-4 inlined stores)

Probably (?) possible to handle, but way way way more easy to break or get wrong (with very-difficult-to-debug consequences) than just some pointer fields.

Oh and also of course, if you store list data in a separate allocation from the main object, you lose the ability to do O(1) (and extremely-cheap at that) "remove self from linked list just given my own pointer", which is probably quite common (and you can't even O(1) with an arraylist instead of a linkedlist).

Re: Rust in the kernel is no longer experimental

#792

Post by wiz21c » Thu, Dec 11, 2025, 9:27 AM UTC

delamon wrote: post #786

estebank wrote: post #652

Earlier quoted context omitted.

Rust wants all memory to be modeled as an ownership tree: the same bit of memory can't be owned by more than one data structure. A doubly linked list breaks that requirement so it can't be modeled in safe Rust directly. The options are using unsafe, or using one of the pointer wrapper types that have runtime checks that ensure correct behavior and own the underlying memory as far Rust is concerned.

Right. So it is not that double-linked lists are inherently unsafe, it is (just) Rust ownership model cannot represent them (any other cyclic structures).

It's not that it cannot, it just doesn't want to :-) (but you're right). I guess that in this very case of DLL, it's a bit hard to swallow. To be honest, it's because the rest of rust really helps me in other areas of my projects that I have accepted that. Learning the ownership model of rust is really painful, it really forces you to code in its way and it was not pleasant to me.

Re: Rust in the kernel is no longer experimental

#793

Post by blub » Thu, Dec 11, 2025, 9:31 AM UTC

m00dy wrote: post #37

C++ devs are spinning in their graves now.

C++ devs don’t care what the Linux kernel’s written in.

But I did see an interesting comment from another user here which also reflects my feelings: Rust is pushed aggressively with different pressure tactics. Another comment pointed out that Rust is not about Rust programmers writing more Rust, but “Just like a religion it is about what other people should do.”.

I’ve been reading about this Rust-in-the-kernel topic since the beginning, without getting involved. One thing that struck me is the obvious militant approach of the rustafarians, criticizing existing maintainers (particularly Ts’o and other objectors), implying they’re preventing progress or out of touch.

The story feels more like a hostile takeover attempt than technology. I also think that many C or C++ programmers don’t bother posting in this topics, so they’re at least partially echo chambers.

Re: Rust in the kernel is no longer experimental

#794

Post by sunshowers » Thu, Dec 11, 2025, 9:34 AM UTC

jacquesm wrote: post #785

sunshowers wrote: post #743

Earlier quoted context omitted.

> Rust should have done exactly one thing and do that as good as possible: be a C replacement and do that while sticking as close as possible to the C syntax. The goal of Rust is to build reliable systems software like the kind I've worked on for the last many years, not to be a better C, the original goal of which was to be portable assembler for the PDP-11. > Now we have something that is a halfway house between C,…

Haskell is interesting, it is probably one of the best programming languages ever devised but it just can't seem to gain traction. There are some isolated pockets where it does well (both business wise as well as geographically).

True!

Re: Rust in the kernel is no longer experimental

#795

Post by blub » Thu, Dec 11, 2025, 9:38 AM UTC

jacquesm wrote: post #505

iurbwdj wrote: post #441

Earlier quoted context omitted.

One perspective is that Rust appears to be forced into the Linux kernel through harassment and pressure. Instead of Rust being pulled, carefully, organically and friendly, and while taking good care of any significant objections. Objections like, getting the relevant features from unstable Rust into stable Rust, or getting a second compiler like gccrs (Linux kernel uses gcc for C) fully up and running, or ensuring th…

I think the main issue is that it never was about how rust programmers should write more rust. Just like a religion it is about what other people should do. That's why you see so many abandoned very ambitious rust projects to tackle x,y or z now written in C to do them all over again (and throw away many years of hardening and bug fixes). The idea is that the original authors can be somehow manipulated into taking th…

Interesting, I was also thinking of the similarities with Jehovah’s witnesses. It’s as if they somehow got into the building, were offered a job and now want to convince everyone of the merits of technical salvation.

Rust the technology is not bad, even though it is still complicated like C++, has rather poor usability (also like C++) and is vulnerable to supply-chain attacks. But some of the people can be very irritating and the bad apples really spoil the barrel. There’s a commenter below gleefully writing that “C++ developers are spinning in their graves”. Probably slightly trolling and mentioning C++ doesn’t make sense in this kernel context, but such hostile, petty comments are not unheard of.

Re: Rust in the kernel is no longer experimental

#796

Post by delamon » Thu, Dec 11, 2025, 10:51 AM UTC

wiz21c wrote: post #792

delamon wrote: post #786

Earlier quoted context omitted.

Right. So it is not that double-linked lists are inherently unsafe, it is (just) Rust ownership model cannot represent them (any other cyclic structures).

It's not that it cannot, it just doesn't want to :-) (but you're right). I guess that in this very case of DLL, it's a bit hard to swallow. To be honest, it's because the rest of rust really helps me in other areas of my projects that I have accepted that. Learning the ownership model of rust is really painful, it really forces you to code in its way and it was not pleasant to me.

I've been trying to convert to Rust an in-memory database and failed. It is strictly single-threaded and full of intrusive lists. I tried hard to please borrow-checker, but one have little choice when internal structures are full of cycles. The result was ugly mess of Rc all over the place. I guess it is just an example of a problem that doesn't fit Rust well.

This makes me wonder: what performance cost Rust code pay due to inability represent cyclic structures efficiently? It seems people tend to design their data in way to please Rust and not in way that would be otherwise more performance efficient.

Re: Rust in the kernel is no longer experimental

#797

Post by pornel » Thu, Dec 11, 2025, 11:54 AM UTC

dwattttt wrote: post #717

ACCount37 wrote: post #494

Earlier quoted context omitted.

Writing C++ is easier than writing Rust. But writing safe multithreaded code in C++? I don't want to write multithreaded C++ at all unless I explicitly want a new hole in my foot. Rust I barely have any experience with, but it might be less frustrating than that.

Anecdotally, my "wow, this Rust business might really go somewhere" moment was when I tried adding multithreading to a random tool I made (dispatching tasks to new threads). Multithreading had not been planned or architected for, it took 30 min, included the compiler informing me I couldn't share a hashmap with those threads unsynchronised, and informing me on how to fix it.

I've had similar experience when the compiler immediately found unsynchronized state deep inside a 3rd party library I've been using. It was a 5-minute fix for what otherwise could have been mysterious unreproducible data corruption.

These days even mobile phones have multicore CPUs, so it's getting hard to find excuses for single-threaded programs.

Re: Rust in the kernel is no longer experimental

#798

Post by jonkoops » Thu, Dec 11, 2025, 11:58 AM UTC

duped wrote: post #537

bayindirh wrote: post #411

Earlier quoted context omitted.

Some pretext: I'm a Rust skeptic and tired of Rust Evangelism Task Force and Rewrite in Rust movements. --- Yes. I remember that message. Also let's not forget what marcan said [0] [1]. In short, a developer didn't want their C codebase littered with Rust code, which I can understand, then the Rust team said that they can maintain that part, not complicating his life further (Kudos to them), and the developer lashing…

> In short, a developer didn't want their C codebase littered with Rust code from reading those threads at the time, the developer in question was deliberately misunderstanding things. "their" codebase wasn't to be "littered" with Rust code - it wasn't touched at all.

Yes, this is it. The Rust code would be in an entirely different part of the project, not touching any of his code, only providing an abstraction for the Rust code to interact with it. The only thing the Rust team asked is to be notified of API changes that they would have to update their bindings for.

Re: Rust in the kernel is no longer experimental

#799

Post by avhception » Thu, Dec 11, 2025, 2:22 PM UTC

vbezhenar wrote: post #747

avhception wrote: post #151

Earlier quoted context omitted.

Your comment comes across disingenuous to me. Writing it in, for example, Java would have limited it to situations where you have the JVM available, which is a minuscule subset of the situations that curl is used in today, especially if we're not talking "curl, the CLI tool" but libcurl. I have a feeling you know that already and mostly want to troll people. And Golang is only 16 years old according to Wikipedia, by…

Java might not be the most popular VM in Linux, but let's talk Perl or Python. It's installed by default almost everywhere, it's probably impossible to find a useful Linux installation without these runtimes. So writing curl with Python makes perfect sense, right? It's memory safe language, good for handling inherently unsafe Internet data. Its startup time is miniscule, compared to typical network response. Lots of…

"[...] it's probably impossible to find a useful Linux installation without [Perl or Python]. [...]"

Oof. We seem to have very, very different definitions for both "Linux" and "useful". If all Linux installs w/o Perl or Python would cease to exist tomorrow, we'd probably enter a global crisis. Industrial processes failing left and right, collapse of wide swaths of internet and telecom infrastructure and god knows what else from ships to cars and smartphones.

Regarding libcurl: libcurl probably represents the vast majority of curl installations. curl the CLI tool is mostly porcelain on top of libcurl. libcurl is used in _a lot_ of places. For example, inside the PHP runtime. And god knows were else, there must be billions of installations as part of other projects. It's not a weird argument, libcurl is 95% of the raison d'être for curl. If you want a curl-like tool in Python or Perl, you gotta write it in Python or Perl. Somebody probably already did. So maybe just use one of these? Instead of demanding that curl be transformed into something which is incompatible with it's mission statement.

Re: Rust in the kernel is no longer experimental

#800

Post by cestith » Thu, Dec 11, 2025, 2:39 PM UTC

hollerith wrote: post #511

jacquesm wrote: post #509

Earlier quoted context omitted.

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.

Aren't large parts of a web browser and a runtime for a programming language also better written in Rust than in Go or Java?

Rust is being used a lot in video and audio processing where C and C++ had been the main players. Fixed-latency streaming is not really the best place for Go, Java, or Python.