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

Rust for Filesystems

lwn.net

Post reply on HN
Print view View original

41–50 of 206 posts

Re: Rust for Filesystems

#41

Post by rcxdude »

lelanthran wrote: post #33
paavohtl wrote: post #17

Earlier quoted context omitted.

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 c…

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

Re: Rust for Filesystems

#42

Post by mjburgess »

tialaramex wrote: post #29
ysw0145 wrote: post #6

Having more options available in the Linux kernel is always beneficial. However, Rust may not be the solution for everything. While Rust does its best to ensure its programming model is safe, it is still a limited model. Memory issues? Use Rust! Concurrency problems? Switch to Rust! But you can't do everything that C does without using unsafe blocks. Rust can offer a fresh perspective to these problems, but it's not…

> But you can't do everything that C does without using unsafe blocks For this particular work the huge benefit of Rust is its enthusiasm for encapsulating such safety problems in types. Which is indeed what this article is about. C and particularly the way C is used in the kernel makes it everybody's responsibility to have total knowledge of the tacit rules. That cannot scale. A room full of kernel developers didn't…

> That cannot scale.

lol... you're talking about the linux kernel, written in C.

The vast majority of software over many decades "bottoms out" in C whether in VMs, operating systems, device drivers, etc.

The scale of the success of C is unparalleled.

Re: Rust for Filesystems

#43

Post by John23832 »

asyx wrote: post #27
bilekas wrote: post #11

Earlier quoted context omitted.

> Concurrency problems? I have to admit, while I do enjoy rust in the sense that it makes sense and can really "click" sometimes. For anything asynchronous I find it really rough around the edges. It's not intuitive what's happening under the hood.

I really hate async rust. It's really great that rust forces you on a compiler level to use mutexes but async is a disease that is spreading through your whole project and introduces a lot of complexity that I don't feel in C#, Python or JS/TS.

Eh, syntactically async rust is the exact same as C#. It's all task based concurrency.

Now, lifetimes attached to function signatures is definitely a problem.

Re: Rust for Filesystems

#44

Post by tucnak »

paavohtl wrote: post #17
tucnak wrote: post #10

Earlier quoted context omitted.

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, a…

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".

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.

Re: Rust for Filesystems

#45

Post by aoieu »

thrance wrote: post #36
aoieu wrote: post #28

Earlier quoted context omitted.

[flagged]

There are obvious differences between criticism and harassment. Let's not act like we don't know why the asahi linux team is getting death threats, and maybe try to improve the situation.

Death threats were being posted on HN? I hope they were swiftly removed if so.

Re: Rust for Filesystems

#46

Post by KallDrexx »

mnau wrote: post #5
gritzko wrote: post #2

From the minutes I conclude that Rust-in-the-kernel looks like an additional complexity tax. I mean, if you write an OS from scratch, you can use the full power of your language. Plastering it to the side of an already vast codebase creates additional issues, as we see here.

> additional complexity tax Yes, but that should be offsetted by easier driver development. See the blog about Rust GPU driver for asahii linux, done in one month. EDIT: Google "tales of the m1 gpu" (author has a very negative opinions about hacker news, read if you like by clicking the link https://asahilinux.org/2022/11/tales-of-the-m1-gpu/ ) Is it universal? We'll see in coming years.

Maybe I'm reading something wrong but the discussion this HN posting is about sounds very much about trying to make a Linux subsystem and API in Rust, so that Rust's type system can enforce conformance to safety mechanisms via its abstraction.

That's fundamentally different and harder than a driver being written in rust that uses the Linux's subsystems C APIs.

I can see a lot of drivers taking on the complexity tax of being written in Rust easily. The complexity tax on writing a whole subsystem in Rust seems like an exponentially harder problem.

Re: Rust for Filesystems

#47

Post by dxroshan »

mjburgess wrote: post #42
tialaramex wrote: post #29

Earlier quoted context omitted.

> But you can't do everything that C does without using unsafe blocks For this particular work the huge benefit of Rust is its enthusiasm for encapsulating such safety problems in types. Which is indeed what this article is about. C and particularly the way C is used in the kernel makes it everybody's responsibility to have total knowledge of the tacit rules. That cannot scale. A room full of kernel developers didn't…

> That cannot scale. lol... you're talking about the linux kernel, written in C . The vast majority of software over many decades "bottoms out" in C whether in VMs, operating systems, device drivers, etc. The scale of the success of C is unparalleled.

I agree with you.

Re: Rust for Filesystems

#48

Post by regularfry »

pjc50 wrote: post #38
thesnide wrote: post #3

Earlier quoted context omitted.

While I agree there are benefits to rust, I tend to think all reason cannot fight hype. The tax will be seen as a necessity to embrace future and progress. I'm wondering why do not restrict ourselves to a safe subset instead of jumping into a huge bandwagon of unknown bugs and tradeoffs

There is no "safe subset" of C. MISRA is fairly close, but all sorts of things that you might need, like integer arithmetic, have potential UB in C. (The best current effort is https://sel4.systems/ , which is written in C but has a large proof of safety attached. The language design question is basically: should the proof be part of the language?)

Given that undefined behaviour just means "undefined by the standard", do you get usefully closer to being able to identify a safe subset with the (MISRA/alternative, specific compiler, specific architecture) triple?

Re: Rust for Filesystems

#49

Post by vollbrecht »

another2another wrote: post #30
vollbrecht wrote: post #8

Earlier quoted context omitted.

One can argue that any additional code is introducing complexity, not only writing Rust. Does that mean we should just stop innovating and go into an indefinite state of maintenance, since we are already so vast? A tax in one place may not be a net negative, if it's used like in the real world to offset other problems. And just saying it will not offset any problems because of a single discussion, that does not have…

>Does that mean we should just stop innovating and go into an indefinite state of maintenance If you mean that not using Rust (or maybe some other languages e.g. Zig or Ada?) means that there can be no innovation in the Linux kernel, I would have to disagree since there's been plenty of progress in plain old c (see for instance io_uring), not to mention the fact that the c language itself could change to make develop…

> If you mean that not using Rust (or maybe some other languages e.g. Zig or Ada?) means that there can be no innovation in the Linux kernel, I would have to disagree since there's been plenty of progress in plain old c.

No i didn't mean that. If i understand OP correctly here, he argued that it is a tax to use rust, a tax is always bad, and thous should be avoided.

We obviously can't now the future. We also can't now how future maintainers look like, and if there will be a bigger abundance of people understanding kernel level C or kernel level Rust or both.

I also don't think that any one developer can claim to fully get every part of the Linux Kernel. So if one person want's to work on a particular subsection they need to make themself familiar with it, independent of the language used. And then we are back at the argument, is the additional tax bad, or what does it bring to the table.

Re: Rust for Filesystems

#50

Post by tucnak »

rcxdude wrote: post #41
lelanthran wrote: post #33

Earlier quoted context omitted.

> 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 c…

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.
Post reply on HN