Hacker News Reader

Comment by tucnak | Hacker News Reader

They simply wish the actual kernel developers just surrendered & weren't in the way of new Rust code. Maybe if these guys wrote C for a living some 10 years or so, became maintainers in their own right, and THEN brought these ideas forward—they would have the chance. But you can't come to the other people's projects, and seriously expect them to just nod ahead to everything you have to say, surrender your concerns, and act like they owe you sommat.

I'm glad this conversation is happening, though.

View on HN

To my knowledge most if not all of these people driving Rust adoption in Linux are seasoned Linux contributors and/or maintainers. They are not outsiders "coming to other people's projects".

> To my knowledge most if not all of these people driving Rust adoption in Linux are seasoned Linux contributors and/or maintainers. They are not outsiders "coming to other people's projects".

Not in this case. It's the Rust evangelist who is the newcomer. FTA:

> Almeida said that he is not trying to keep the C API static; his goal is to get the filesystem developers to explain the semantics of the API so that they can be encoded into Rust.

The responses from the kernel team members to the proposal seem reasoned and mature to me:

> In addition, when the C code changes, the Rust code needs to follow along, but who is going to do that work?

> As the C code evolves, which will happen more quickly than with the Rust code, at least initially, there will be a need to keep the two APIs in sync.

> The object lifecycles are being encoded into the Rust API, but there is no equivalent of that in C; if someone changes the lifecycle of the object on one side, the other will have bugs.

> Encoding a single lifecycle understanding into the API means that its functions will not work for some filesystems.

> Part of the problem, Ted Ts'o said, is that there is an effort to get "everyone to switch over to the religion" of Rust; that will not happen, he said, because there are 50+ different filesystems in Linux that will not be instantaneously converted.

> Bottomley said that as more of those semantics get encoded into the bindings, they will become more fragile from a synchronization standpoint

> But Ts'o pointedly said that not everyone will learn Rust; if he makes a change, he will fix all of the affected C code, but, "because I don't know Rust, I am not going to fix the Rust bindings, sorry".

> Not in this case. It's the Rust evangelist who is the newcomer. FTA:

From a quick search, I've found that the person is somewhat active in kernel commits over the last four years (mostly but not all rust related from what I see) and is involved in some lkml stuff and some commits over a decade ago. Not sure if this makes him a newcomer or not, just wanted to provide a bit more context.

The other person behind the proposal, is however a seasoned kernel developer, with >14 years of experience working in the FS subsystem of linux.

This is case-in-point; bcachefs maintainer is merely _entertaining_ the ideas proposed by the Rust evangelist, with the express intent of exploring alternatives... and suddenly it's enough for "the movement" to co-opt him into the "proposal" [to include Rust in the FS subsystem], it seeems. Are Rust supporters really as desperate so-as to co-opt ANY interest in the subject?? This toxicity is not helping anybody.

I think you're misunderstanding the situation.

Kent Overstreet is the bcachefs maintainer and he's extremely pro-Rust. He has in fact talked about wanting to move bcachefs to Rust, and the userspace tools for bcachefs are already written in Rust.

He's been participating in the mailing list discussions about using Rust / providing Rust APIs for the FS subsystem.

I don't know who you're confusing him with, but you're confusing him with someone else.

I'm not sure what you are saying. Maybe the first proposal isn't the best one, so some exploration is warranted.

Is Kent an unwilling pawn in the game of getting Rust implemented in the Linux kernel? Or is he not serious enough about getting it in that his support should not be considered?

From what I've seen it reads to me Kent would be very happy to implement bcachefs in Rust in the Linux kernel. Bcachefs-tools does make use of it.

Kent has been really vocal about writing bcachefs in Rust in the IRC channel. They even started some work already, but decided to wait until the common abstractions are ready and merged.

This is a common misconception; like every movement of "revolutionary" modus, it likes to over-represent its supporter base & amplify the chosen ambassadors. So whenever some kind of concession, or endorsement is made—it's immediately read, and amplified as indicative of a greater support, and/or change.

Perhaps a better approach would have been for Linus to design his own backwards-compatible and safer fork of the C language, and have the kernel gradually rewritten in that.

He's already written - with a considerable amount of collaboration of course - the world's most popular kernel and the world's most popular source control system. I expect he'd be able to do the same for a new and improved systems language if he put his mind to it.

> backwards-compatible and safer

Pick one.

The safety is achieved by eliminating constructs which cannot be proven to be safe. Additionally, Rust-style safety involves adding more information explicitly to the source which otherwise has to be kept in the programmer's head (or externally like sel4): object lifetimes, lock rules (see original article), etc.

At best you end up with "first wrap all your original code in 'unsafe' and then gradually move the safety boundary", but even that is very difficult.

Not advocating for this, but you could also imagine a C superset where all of the new features only apply in 'safe' blocks, which would be backwards-compatible, and likely safer-in-practice.

A C variant that e.g. defined OOB access to segfault (or panic in this case) would be strictly safer while being fully compatible with all valid C code. Not that I'm advocating for such a C variant but your snide retort is simply wrong: there is plenty of room for making C safer without reinventing the wheel.

Note that the Linux kernel is already written with C 'extensions' not in pure C.

Reply on news.ycombinator.com