Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust in the kernel is no longer experimental

lwn.net

Post reply on HN
Print view View original

211–220 of 853 posts

Re: Rust in the kernel is no longer experimental

#211

Post by ACCount37 »

jandrewrogers wrote: post #121
lmm wrote: post #46

Earlier quoted context omitted.

> Obviously not Is it obvious? I haven't heard of new projects in non-memory-safe languages lately, and I would think they would struggle to attract contributors.

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…

There's a "point of no return" when you start to struggle to hire anyone on your teams because no one knows the language and no one is willing to learn. But C++ is very far from it.

Re: Rust in the kernel is no longer experimental

#212

Post by dwattttt »

mort96 wrote: post #203
dcrazy wrote: post #64

Does the removal of “experimental” now mean that all maintainers are now obligated to not break Rust code?

No maintainer is obligated to not break any part of Linux other than the user space API, there are no stable in-kernel APIs

There is, I understand, an expectation that if you do make breaking changes to kernel APIs, you fix the callers of such APIs. Which has been a point of contention, that if a maintainer doesn't know Rust, how would they fix Rust users of an API?

The Rust for Linux folks have offered that they would fix up such changes, at least during the experimental period. I guess what this arrangement looks like long term will be discussed ~now.

Re: Rust in the kernel is no longer experimental

#213

Post by Imustaskforhelp »

simonask wrote: post #208
mort96 wrote: post #203

Earlier quoted context omitted.

No maintainer is obligated to not break any part of Linux other than the user space API, there are no stable in-kernel APIs

What they mean is that the Linux kernel has a long-standing policy to keep the whole kernel compilable on every commit, so any commit that changes an internal API must also fix up _all_ the places where that internal API is used. While Rust in the kernel was experimental, this rule was relaxed somewhat to avoid introducing a barrier for programmers who didn't know Rust, so their work could proceed unimpeded while the…

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

Re: Rust in the kernel is no longer experimental

#214

Post by oblio »

jcranmer wrote: post #32
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.

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 (with a degree of asterisks on the last two). 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. Leaving this set of mandatory languages is difficult (I think Fortran,…

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.

Re: Rust in the kernel is no longer experimental

#217

Post by StopDisinfo910 »

markus_zhang wrote: post #11

Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be gradually converted to safer languages?

Depends of what you do.

Rust has a nice compiler-provided static analyzer using annotation to do life time analysis and borrow checking. I believe borrow checking to be a local optima trap when it comes to static analysis and finds it often more annoying to use than I would like but I won't argue it's miles better than nothing.

C has better static analysers available. They can use annotations too. Still, all of that is optional when it's part of Rust core language. You know that Rust code has been successfully analysed. Most C code won't give you this. But if it's your code base, you can reach this point in C too.

C also has a fully proven and certified compiler. That might be a requirement if you work in some niche safety critical applications. Rust has no equivalent there.

The discussion is more interesting when you look at other languages. Ada/Spark is for me ahead of Rust both in term of features and user experience regarding the core language.

Rust currently still have what I consider significant flaws: a very slow compiler, no standard, support for a limited number of architectures (it's growing), it's less stable that I consider it should be given its age, and most Rust code tends to use more small libraries than I would personaly like.

Rust is very trendy however and I don't mean that in a bad way. That gives it a lot of leverage. I doubt we will ever see Ada in the kernel but here we are with Rust.

Re: Rust in the kernel is no longer experimental

#218

Post by SSLy »

hgs3 wrote: post #202
inapis wrote: post #172

Earlier quoted context omitted.

I am not a system programmer but, from my understanding, Torvalds has expressed strong opinions about microkernels over a long period of time. The concept looks cleaner on paper but the complexity simply outweighs all the potential benefits. The debate, from what I have followed, expressed similar themes as monolithic vs microservices in the wider software development arena.

I'm not a kernel developer myself, but I’m aware of the Tanenbaum/Torvalds debates in the early 90’s. 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. And thanks for attempting to answer my question without snark or down voting. Usually HN is much better for discussion than this.

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

Re: Rust in the kernel is no longer experimental

#219

Post by hantusk »

bryanrasmussen wrote: post #209

really? I recently read that "A 100% Rust kernel is now upstream in Linux 7.4"

you're joking because of the other frontpage story with Gemini 3 hallucinating hacker news 10 years in the future, but still lets keep the hallucinations to that page.

Re: Rust in the kernel is no longer experimental

#220

Post by otikik »

markus_zhang wrote: post #11

Not a system programmer -- at this point, does C hold any significant advantage over Rust? Is it inevitable that everything written in C is going to be gradually converted to safer languages?

Ubiquity is still a big one. There's many, many places where C exists that Rust has not reached yet.
Post reply on HN