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

91–100 of 206 posts

Re: Rust for Filesystems

#91

Post by genrilz »

atoav wrote: post #15
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…

Obviously, there are some cases where it makes sense to use an unsafe block. However, I think there might be fewer cases then people might think.

As an example, both the popular generic self-referencing crates ouroboros and self_cell have had memory safety bugs in them in the past. (links at the end) Both of them were carefully reviewed by experienced rust developers before their first public release, and yet they still ended up with such bugs. Admittedly, part of the issue is that both crates are trying to be more generic, so they have to be correct over a larger range of circumstances.

But still, these crates have one job, are both less than 1500 LOC, and they were carefully reviewed to ensure they did that one job before their public releases, and they still ended up having issues that were not caught. They might still have issues.

Thus, while it might be fine to use unsafe to state that your array of zeros is a valid utf-8 string without a runtime check, it's probably a good idea to twist yourself into a pretzel if the invariants are not trivial to prove and the overhead to maintenance/runtime isn't too high.

[0]: https://rustsec.org/advisories/RUSTSEC-2023-0042.html [1]: https://rustsec.org/advisories/RUSTSEC-2023-0070.html

Re: Rust for Filesystems

#92

Post by tucnak »

abenga wrote: post #86
Firmwarrior wrote: post #69

Earlier quoted context omitted.

[flagged]

Hmmm. Is this serious or facetious? Or could be either, depending on the response? There already is rust code in the Linux kernel (some drivers), afaik.

Linus strategy on Rust is genius, albeit immoral. — Don't engage the movement head-on, make concessions where it doesn't matter. — Nobody wants to write drivers? No problem, have THEM write the drivers where the impact is minimal. I believe, if Rust people really understood how they're being used exactly, they wouldn't bother with it, and would go on to write more impactful code. And yet, Linus had managed to execute this strategy perfectly; the insult is subtle enough not to cause major injury.

Re: Rust for Filesystems

#93

Post by pjc50 »

tucnak wrote: post #88
_flux wrote: post #77

Earlier quoted context omitted.

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…

[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 larger and more complicated language than C)

Re: Rust for Filesystems

#94

Post by dralley »

tucnak wrote: post #50
rcxdude wrote: post #41

Earlier quoted context omitted.

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.

Re: Rust for Filesystems

#95

Post by doublepg23 »

Firmwarrior wrote: post #69
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".

[flagged]

? I have a friend who was working on "smart grid" code in Rust way back in 2018. Rust code already ships in Android and Firefox too.

Re: Rust for Filesystems

#96

Post by John23832 »

colejohnson66 wrote: post #56
John23832 wrote: post #43

Earlier quoted context omitted.

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.

Not really. C#'s Task/Task are based on background execution. Once something is awaited, control is returned to the caller. OTOH, Rust's Future is, by default, based on polling/stepping, a bit like IEnumerable in C#; If you never poll/await the Future , it never executes. Executor libraries like Tokio allow running futures in the background, but that's not built-in.

I don't want to "well actually" the "well actually", but I think you missed the word syntactically.

> C#'s Task/Task are based on background execution. Once something is awaited, control is returned to the caller.

Async/await in any language happens in the background.

What happens during a Task.Yield() (C#)? The task is yielded to the another awaiting task in the work queue. Same as Rust.

> OTOH, Rust's Future is, by default, based on polling/stepping,

The await syntax abstracts over Future/Stream polling. The real difference is that Rust introduced the Future type/concept of polling at all (which is a result of not having a standard async runtime). There is a concept of "is this task available to proceed on" in C# too, it's just not exposed to the user and handled by the CLR.

Re: Rust for Filesystems

#97

Post by dralley »

Firmwarrior wrote: post #69
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".

[flagged]

Rust is a thing in the real world.

Both Windows and Android are shipping, today, with meaningful components written in Rust. Amazon S3 and Lambda are built on top of Rust. Apple is hiring Rust developers and they post about it on this platform [https://news.ycombinator.com/item?id=40849188]. Dropbox and Discord backend services are written in Rust. Cloudflare uses Rust very extensively in their infrastructure, which means that a large fraction of global internet traffic passes through routers and servers written in Rust. The UEFI firmware implementation of the next Surface products by Microsoft is written in Rust.

You are simply incorrect. Instead of arguing I will suggest that you do a slight modicum of research into who is using Rust and for what. While it won't be comparable in omnipresence with C and C++ for a long time, it is widely-enough used that there is a near-zero chance that you are not already using some tool or service that directly or indirectly uses Rust for some significant purpose. It is not a "forum and hobby project language". The list I just provided is also by no means complete - Shopify, Disney, Facebook, Firefox... and many others... also use Rust.

Your claim of credibility via working on kernels falls completely flat in the face of Microsoft directly contradicting you: https://www.thurrott.com/windows/282471/microsoft-is-rewriti...

"According to Weston, Microsoft has already rewritten 36,000 lines of code in the Windows kernel in Rust, in addition to another 152,000 lines of code it wrote for a proof of concept DirectWrite Core library, and the performance is excellent with no regressions compared to the old C++ code. He also called out that “there is now a syscall, in the Windows kernel, written in Rust.”

Whatever experience you have is out of date with the current reality. Not only is there interest in using Rust in these core areas, but it has already started happening.

Re: Rust for Filesystems

#98

Post by dboreham »

the_duke wrote: post #82
bilekas wrote: post #26

Earlier quoted context omitted.

> Async != concurrency. Right, but tasks are sharing the same thread which is fine, but when we need to expand on that with them actually working async, i.e non blocking, fire and quasi-forget, its tricky. That's all I'm saying.

The Rust async experience indeed has lots of pitfalls, very much agree there.

s/The Rust/All/

Re: Rust for Filesystems

#99

Post by lelanthran »

olivermuty wrote: post #20
eru wrote: post #14

Earlier quoted context omitted.

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.

> Or as other people like to call it: "A real concern described in an apt manner".

Oh please. Every activist for every marginal issue says the same thing. Doesn't make it true.

Re: Rust for Filesystems

#100

Post by germandiago »

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

I like Linus view on evolution. Evolution will tell what the most sensible choices are over time. It is like "the market" in some way. Let everyone make their bets, wait, see, analyze, research. That's it.
Post reply on HN