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

121–130 of 206 posts

Re: Rust for Filesystems

#121

Post by account42 »

pjc50 wrote: post #35
aoieu wrote: post #25

Earlier quoted context omitted.

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…

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

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.

Re: Rust for Filesystems

#122

Post by frankjr »

lambda wrote: post #119
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…

Calling C from Rust can be quite simple. You just declare the external function and call it. For example, straight out of the Rust book https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#usin... : extern "C" { fn abs(input: i32) -> i32; } fn main() { unsafe { println!("Absolute value of -3 according to C: {}", abs(-3)); } } Now, if you have a complex library and don't want to write all of the declarations by han…

There's also cbindgen for going the other way around. https://github.com/mozilla/cbindgen

Re: Rust for Filesystems

#123

Post by brodouevencode »

> about the disconnect between the names in the C API and the Rust API, which means that developers cannot look at the C code and know what the equivalent Rust call would be

Ah, the struggle of legacy naming conventions. I've had success in keeping the same name but when I wanted an alternative name I would just wrap the old name with the new name.

But yeah, naming things is hard.

Re: Rust for Filesystems

#124

Post by bcaltcx »

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.

[flagged]

Re: Rust for Filesystems

#125

Post by BiteCode_dev »

nickparker wrote: post #118
BiteCode_dev wrote: post #84

Given how those discussions usually go, and the scale of the change, I find that discussion extraordinarily civil. I disagree with the negative tone of this thread, I'm quite optimistic given how clearly the parties involved were able to communicate the pain points with zero BS.

I found myself reading this more for the excellent notetaking than for the content. I suspect the discussion was about as charged, meandering, and nitpicky as we all expect a PL debate among deeply opinionated geeks to be, and Jake Edge (who wrote this summary) is exceptionally good at removing all that and writing down substance.

Certainly.

We are talking about extremely competent people who worked on a critical piece of software for years and invested a lot of their lives in it, with all pain, effort, experience, and responsibilities that come with that.

That this debate is inscribed is a process that is still ongoing, and in fact, progressing, is a testament to how healthy the situation is.

I was expecting the whole Rust thing to be shut down 10 times, in a flow of distasteful remarks, already.

This means that not only Rust is vindicated as promising for the job, but both teams are willing and up to the task of working on the integration.

Those projects are exhausting, highly under-pressure situations, and they last a long time.

I still find that the report is showing a positive outcome. What do people expect? Move fast and break things?

A barrage of "no" is how it's supposed to go.

Re: Rust for Filesystems

#126

Post by varjag »

lambda wrote: post #119
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…

Calling C from Rust can be quite simple. You just declare the external function and call it. For example, straight out of the Rust book https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#usin... : extern "C" { fn abs(input: i32) -> i32; } fn main() { unsafe { println!("Absolute value of -3 according to C: {}", abs(-3)); } } Now, if you have a complex library and don't want to write all of the declarations by han…

That's not really "simple", it's on par with C FFI in about any other language (except C++), with same drawbacks.

Re: Rust for Filesystems

#127

Post by wongarsu »

KallDrexx wrote: post #46
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.

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

You could just write rust code that calls the C APIs, and that would probably avoid a lot of discussions like the one in the article.

But making good wrappers would make development of downstream components even easier. As the opponents in the discussion said: there's about 50 filesystem drivers. If you make the interface better that's a boon for every file system (well, every file system that uses rust, but it doesn't take many to make the effort pay off). You pay the complexity tax once for the interface, and get complexity benefits in every component that uses the interface.

We would have the same discussions about better C APIs, if only C was expressive enough to allow good abstractions.

Re: Rust for Filesystems

#128

Post by tucnak »

pjc50 wrote: post #108
tucnak wrote: post #102

Earlier quoted context omitted.

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

The only people to "hate" on Linux are the Rust community; in fact, they genuinely DESPISE the Linux maintainers for allowing themselves to be so brazenly exploited over the years. This is akin to how communists despise the workers.

Now, as for me: I respect Rust, not hate it, and only sympathise / pity the wider Rust movement. I believe their resources are much better spent someplace else: NOT bickering over decades-old operating systems and getting into the other people's codebases (this is what pleading for "common abstractions" is, really.) Had they learnt to stop competing for popularity and recognition, they would be very successful in validating the borrowing hypothesis. The conviction is not there: had there been conviction, heart, and commitment, they wouldn't bother with old codebases, and would instead make something special.

P.S. I don't require hate to be superior, my nature is sufficient to that end.

Re: Rust for Filesystems

#129

Post by [deleted] »

tucnak wrote: post #128
pjc50 wrote: post #108

Earlier quoted context omitted.

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.

The only people to "hate" on Linux are the Rust community; in fact, they genuinely DESPISE the Linux maintainers for allowing themselves to be so brazenly exploited over the years. This is akin to how communists despise the workers. Now, as for me: I respect Rust, not hate it, and only sympathise / pity the wider Rust movement. I believe their resources are much better spent someplace else: NOT bickering over decades…

[deleted]

Re: Rust for Filesystems

#130

Post by jcranmer »

pessimizer wrote: post #74
pjc50 wrote: post #39

Earlier quoted context omitted.

> I refuse to believe that any single person would not want to stop someone from bullying someone else into their own suicide! There are plenty of people who do want the freedom to say exactly what they choose, including a lengthy period of directed harassment, and shrug their shoulders if someone commits suicide over it. There's not much that can be done other than ban them from civilized spaces.

"Bullying" is a judgement. Intrinsic to the word is a judgement that what is being done is bad, and the person doing it would not describe it that way. And by that I don't mean that it's not bad to bully people (it's rather tautological), I mean that talk of bullying often begs the question, and is intentionally done in order to elide past the actual events that occurred. Lèse majesté laws against talking about the K…

What the referer-replacement page was talking is Kiwi Farms, which is doing the kind of stuff that even the US First Amendment's very expansive protections fails to protect. (The criminal liability here is "intentional inflection of emotional distress", although note that most lawsuits that allege that are groundless lawsuits that largely fail to make it pass the motion to dismiss for failure to state a claim stage as "they made me feel bad" isn't sufficient to allege an IIED).
Post reply on HN