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

81–90 of 206 posts

Re: Rust for Filesystems

#81

Post by another2another »

mjburgess wrote: post #76
pjc50 wrote: post #51

Earlier quoted context omitted.

The scale of C adoption is certainly unparalleled over the past 40 or so years, but so are the safety issues in the cyberwarfare era. https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/pre... If, somehow, we'd got to an era where (a) operating systems were widely deployed in a different language, and (b) the Morris Worm of 1988 had happened due to buffer overflow issues, then C in its current form would never h…

C is just convenient assembly. In an era where performance mattered, and much software was written for hardware, and controlling hardware, it's hard to see an alternative. C's choices were for performance on hardware-limited systems. I don't really see what other ones made sense historically.

>In an era where performance mattered, and much software was written for hardware, and controlling hardware, it's hard to see an alternative

Actually, what made sense _was_ assembly when performance mattered above all. C was actually seen as a higher level language.

However C's advantage was the fact that it was cross platform, so you could compile or quite easily port the same code to many different platforms with a C compiler (Solaris,Windows,BSD,Linux and latterly Mac OSX). That was its strength (pascal shared this too, but it didn't survive).

You can see this in the legacy of software that's still in use today - lots of gnu utilities, shells, X windows, the zlib library, the gcc, openssl and discussed fairly recently POV Ray which has been going since the 80's.

Re: Rust for Filesystems

#82

Post by the_duke »

bilekas wrote: post #26
the_duke wrote: post #21

Earlier quoted context omitted.

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

Re: Rust for Filesystems

#83

Post by guitarbill »

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 kids need to quit tricking other entry level aspiring OS devs into wasting their time learning this language.

In that case, C/C++ developers need to quit tricking the rest of the world that C/C++ is a suitable language for anything security related and - for commercial products - take responsibility for the economic and social impact for the data breaches due to memory safety issues.

(I really don't care if it's Rust, Java, C#, whatever.)

Re: Rust for Filesystems

#84

Post by BiteCode_dev »

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.

Re: Rust for Filesystems

#85

Post by tupshin »

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…

This is not a notable challenge in rust, nor relevant to the article.

The article is about finding ways of using rust to actually implement kernel fs drivers/etc. Note that any rust code in the kernel is necessarily consuming C interfaces.

Bindgen works quite well for the use case that you are thinking.

https://github.com/rust-lang/rust-bindgen

Re: Rust for Filesystems

#86

Post by abenga »

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]

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.

Re: Rust for Filesystems

#87

Post by [deleted] »

hu3 wrote: post #75

Some of the comments below the lwn.net page are rather disrespectful. Imagine getting this comment about the open source project you contribute to: "Science advances one funeral at a time"

[deleted]

Re: Rust for Filesystems

#88

Post by tucnak »

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

[flagged]

Re: Rust for Filesystems

#89

Post by Ygg2 »

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

Yeah, you just renamed `unsafe`.

`unsafe` is the part where the compiler trusts you to uphold your own invariants, necessary to prevent Unsoundness. For example:

- unsafe fn get_unchecked(index) - compiler believes you will ensure index - unsafe fn set_capacity(capacity) - compiler trusts you will not set capacity to value that will cause UB. Even if its code boils essentially to set a field - which is safe according to Rust, but may invalidate other invariants preserving soundness.

Re: Rust for Filesystems

#90

Post by pjc50 »

mjburgess wrote: post #76
pjc50 wrote: post #51

Earlier quoted context omitted.

The scale of C adoption is certainly unparalleled over the past 40 or so years, but so are the safety issues in the cyberwarfare era. https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/pre... If, somehow, we'd got to an era where (a) operating systems were widely deployed in a different language, and (b) the Morris Worm of 1988 had happened due to buffer overflow issues, then C in its current form would never h…

C is just convenient assembly. In an era where performance mattered, and much software was written for hardware, and controlling hardware, it's hard to see an alternative. C's choices were for performance on hardware-limited systems. I don't really see what other ones made sense historically.

C is, in some important cases, less convenient than assembly in ways which have to be worked round either fooling the compiler or adding intrinsics. A recent example: https://justine.lol/endian.html

Is the huge macro more convenient than the "bswap" instruction? No, but it's portable.

> I don't really see what other ones made sense historically.

Pascal chose differently in a couple of places. In particular, carrying the length with strings.

C refused to define semantics for arithmetic. This gave you programs which were "portable" so long as you didn't mind different behavior on different platforms. Good for adoption, bad for sanity. It was only relatively recently they defined subtraction to be twos-complement.

16-bit Windows even used C with the Pascal calling convention. http://www.c-jump.com/CIS77/ASM/Procedures/P77_0070_pascal_s...

Post reply on HN