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

101–110 of 206 posts

Re: Rust for Filesystems

#101

Post by wongarsu »

bilekas wrote: post #11
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.

Rust async isn't all that pleasant to use. On the other hand for normal threaded concurrency Rust is one of the best languages around. The type system prevents a lot of concurrency bugs. "Effortless concurrency" is a tagline the language really has earned.

Re: Rust for Filesystems

#102

Post by tucnak »

pjc50 wrote: post #93
tucnak wrote: post #88

Earlier quoted context omitted.

[flagged]

> But they don't want to be writing file systems; instead, the only goal that matters to them is getting to the heart of the most popular OS, so as to secure some longterm success. Wrong final word: security . In the war against remote exploits, harden the most widely used target first. Rust only exists because getting people to reliably and consistently write secure C++ proved impossible. (yes I know C++ is a much l…

[flagged]

Re: Rust for Filesystems

#103

Post by crest »

pornel wrote: post #73

I don't get how can each file system have a custom lifecycle for inodes, but still use the same functions for inode lifecycle management, but apparently with different semantics? That sounds like the opposite of an abstraction layer, if the same function must be used in different ways depending on implementation details. If the lifecycle of inodes is filesystem-specific, it should be managed via filesystem-specific f…

I assume it's supposed to work by having the compiler track the lifetime of the inodes. The compiler is expected to help with ephemeral references (the file system still has to store the link count to disk).

Re: Rust for Filesystems

#104

Post by codetrotter »

gwbas1c wrote: post #78

Maybe they are asking the wrong questions? Does Rust need to change to make it easier to call C? I've done a bit of Rust, and (as a hobbyist,) it's still not clear (to me) how to interoperate with C. (I'm sure someone reading this has done it.) In contrast, in C++ and Objective C, all you need to do is include the right header and call the function. Swift lets you include Objective C files, and you can call C from th…

I’ve written Rust code that called C++

It wasn’t completely straightforward, but on the whole I figured out everything I needed to within a few days in order to be able to do it.

Calling C would surely be very similar.

Re: Rust for Filesystems

#105

Post by pimeys »

_flux wrote: post #77
tucnak wrote: post #50

Earlier quoted context omitted.

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'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 doe…

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.

Re: Rust for Filesystems

#106

Post by tracker1 »

fla wrote: post #57
atoav wrote: post #15

Earlier quoted context omitted.

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…

I like the idea of using: trusted { … }

    trustMeBro { ... }

Re: Rust for Filesystems

#107

Post by duped »

gwbas1c wrote: post #78

Maybe they are asking the wrong questions? Does Rust need to change to make it easier to call C? I've done a bit of Rust, and (as a hobbyist,) it's still not clear (to me) how to interoperate with C. (I'm sure someone reading this has done it.) In contrast, in C++ and Objective C, all you need to do is include the right header and call the function. Swift lets you include Objective C files, and you can call C from th…

It's actually pretty easy. All you need is declare `extern "C" fn foo() -> T` to be able to call it from Rust, and to pass the link flags either by adding a #[link] attribute or by adding it in a build.rs.

You can use the bindgen crate to generate bindings ahead of time, or in a build.rs and include!() the generated bindings.

Normally what people do is create a `-sys` crate that contains only bindings, usually generated. Then their code can `use` the bindings from the sys crate as normal.

> in contrast, in C++ and Objective C, all you need to do is include the right header

and link against the library.

Re: Rust for Filesystems

#108

Post by pjc50 »

tucnak wrote: post #102
pjc50 wrote: post #93

Earlier quoted context omitted.

> But they don't want to be writing file systems; instead, the only goal that matters to them is getting to the heart of the most popular OS, so as to secure some longterm success. Wrong final word: security . In the war against remote exploits, harden the most widely used target first. Rust only exists because getting people to reliably and consistently write secure C++ proved impossible. (yes I know C++ is a much l…

[flagged]

Man, an omni-hater, not just hating people trying to bring Rust to Linux but also hating on Linux. Must be a very rewarding sense of superiority.

> ECC memory

This is entirely Intel's fault.

Re: Rust for Filesystems

#109

Post by sandywaffles »

I wasn't clear and am not familiar enough with the Linux FS systems to know if this Rust API would be wrapping or re-implementing the C APIs? If it's re-implementing (or rather an additional API) it seems keeping the names the same as the C API would be problematic and lead to more confusion over time, even if initially it helped already-familiar-developers grok whats going on faster.

Re: Rust for Filesystems

#110

Post by duped »

the_duke wrote: post #21
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.

Async != concurrency. One of the major wins of Rust is encoding thread safety in the type system with the `Send` and `Sync` traits.

async == concurrency, concurrency != parallelism.
Post reply on HN