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

11–20 of 206 posts

Re: Rust for Filesystems

#11

Post by bilekas »

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…

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

Re: Rust for Filesystems

#12

Post by weinzierl »

sanxiyn wrote: post #9
drdo wrote: post #7

Earlier quoted context omitted.

But unsafe blocks are available! And you should use them when you have to, but only when you have to. Using an unsafe block with a very limited blast radius doesn't negate all the guarantees you get in all the rest of your code.

Note that unsafe blocks don't have limited blast radius. Blast that can be caused by a single incorrect unsafe block is unlimited, at least in theory. (In practice there could be correlation of amount of incorrectness to effect, but same also could be said about C undefined behavior.) Unsafe blocks limit amount you need to get correct, but you need to get all of them correct. It is not a blast limiter.

Yes, they don't contain the blast, but they limit the places where a bomb can be, and that is their worth.

Re: Rust for Filesystems

#13

Post by CraigJPerry »

drdo wrote: post #7
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 unsafe blocks are available! And you should use them when you have to, but only when you have to. Using an unsafe block with a very limited blast radius doesn't negate all the guarantees you get in all the rest of your code.

I’d word that different- it reduces the search space for a bug when something goes wrong but it doesn’t limit the blast radius - you can still spectacularly blow up safe rust code with an unsafe block (that no aliases rule is seriously tough to adhere to!)

This is definitely a strong benefit though.

Re: Rust for Filesystems

#14

Post by eru »

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.

Alas, that link just gets you a rant about politics, if you click on it directly.

Copy-and-pasting works.

Re: Rust for Filesystems

#15

Post by atoav »

aoieu wrote: post #4

[flagged]

But I'd rather have 50 lines of nuclear fissile code that needs to be correct than say the whole software.

The danger of Rust it that you twist yourself into a bretzel in order to avoid unsafe, while you should have in fact made a exceptionally well tested and designed unsafe block that is surrounded by code that the compiler checks for you.

I am still convinced that the naming choice for unsafe has some effects that were not intended. Mentally whenever you see unsafe fill in a "trust me" or a "manual override" or whatever. Something that tells you that the programmer had a reason to override the borrow-checker. If they are cool they tell you why the thing they did is indeed safe and sound code.

Re: Rust for Filesystems

#16

Post by Already__Taken »

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.

reads a lot like letting perfect be the enemy of good.

Re: Rust for Filesystems

#17

Post by paavohtl »

tucnak wrote: post #10
aoieu wrote: post #4

[flagged]

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

Re: Rust for Filesystems

#18

Post by [deleted] »

drdo wrote: post #7
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 unsafe blocks are available! And you should use them when you have to, but only when you have to. Using an unsafe block with a very limited blast radius doesn't negate all the guarantees you get in all the rest of your code.

[deleted]

Re: Rust for Filesystems

#19

Post by Yoric »

thesnide wrote: post #3
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.

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

Safe subset of what?

Re: Rust for Filesystems

#20

Post by olivermuty »

eru wrote: post #14
mnau wrote: post #5

Earlier quoted context omitted.

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

Alas, that link just gets you a rant about politics, if you click on it directly. Copy-and-pasting works.

"Rant about politics", haha. Or as other people like to call it: "A real concern described in an apt manner".

I have observed these inflammatory sub-graphs of comments myself and have thought to myself that this must be a huge growing grounds for unmoderated and unwanted behaviour because it more or less becomes invisible once flagged enough.

Post reply on HN