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

51–60 of 206 posts

Re: Rust for Filesystems

#51

Post by pjc50 »

mjburgess wrote: post #42
tialaramex wrote: post #29

Earlier quoted context omitted.

> But you can't do everything that C does without using unsafe blocks For this particular work the huge benefit of Rust is its enthusiasm for encapsulating such safety problems in types. Which is indeed what this article is about. C and particularly the way C is used in the kernel makes it everybody's responsibility to have total knowledge of the tacit rules. That cannot scale. A room full of kernel developers didn't…

> That cannot scale. lol... you're talking about the linux kernel, written in C . The vast majority of software over many decades "bottoms out" in C whether in VMs, operating systems, device drivers, etc. The scale of the success of C is unparalleled.

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 have been adopted.

Re: Rust for Filesystems

#52

Post by fwip »

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…

Not advocating for this, but you could also imagine a C superset where all of the new features only apply in 'safe' blocks, which would be backwards-compatible, and likely safer-in-practice.

Re: Rust for Filesystems

#53

Post by thrance »

aoieu wrote: post #45
thrance wrote: post #36

Earlier quoted context omitted.

There are obvious differences between criticism and harassment. Let's not act like we don't know why the asahi linux team is getting death threats, and maybe try to improve the situation.

Death threats were being posted on HN? I hope they were swiftly removed if so.

You should probably read the asahi linux post.

Re: Rust for Filesystems

#54

Post by pjc50 »

regularfry wrote: post #48
pjc50 wrote: post #38

Earlier quoted context omitted.

There is no "safe subset" of C. MISRA is fairly close, but all sorts of things that you might need, like integer arithmetic, have potential UB in C. (The best current effort is https://sel4.systems/ , which is written in C but has a large proof of safety attached. The language design question is basically: should the proof be part of the language?)

Given that undefined behaviour just means "undefined by the standard", do you get usefully closer to being able to identify a safe subset with the (MISRA/alternative, specific compiler, specific architecture) triple?

No, undefined behavior does not mean "not defined by the standard", it means those places where the standard says "undefined behavior". And then the long and complicated war over "the compiler may assume that UB does not happen and then optimize on that basis".

You might be able to tighten it up in some specific cases, and those battles are being fought elsewhere, but there's stuff like lock lifetimes which you cannot do without substantial extra annotations inside or outside the language.

Re: Rust for Filesystems

#55

Post by [deleted] »

aoieu wrote: post #45
thrance wrote: post #36

Earlier quoted context omitted.

There are obvious differences between criticism and harassment. Let's not act like we don't know why the asahi linux team is getting death threats, and maybe try to improve the situation.

Death threats were being posted on HN? I hope they were swiftly removed if so.

[deleted]

Re: Rust for Filesystems

#56

Post by colejohnson66 »

John23832 wrote: post #43
asyx wrote: post #27

Earlier quoted context omitted.

I really hate async rust. It's really great that rust forces you on a compiler level to use mutexes but async is a disease that is spreading through your whole project and introduces a lot of complexity that I don't feel in C#, Python or JS/TS.

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.

Re: Rust for Filesystems

#57

Post by fla »

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…

I like the idea of using:

  trusted { … }

Re: Rust for Filesystems

#58

Post by [deleted] »

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…

[deleted]

Re: Rust for Filesystems

#60

Post by logicprog »

aoieu wrote: post #28
olivermuty wrote: post #20

Earlier quoted context omitted.

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

[flagged]

> I've not read any of these comments but it sounds like the author of that message is somewhat peeved at the fact he can't control the conversation of others.

Are you fucking serious right now? Did you actually read what they said? Want is wrong with you? They're not "peeved" about "not being able to control the conversations of others", they're pointing out that because of Hacker News's lax and irresponsible moderation and disturbing overlap with much worse communities, it is a breeding ground for endless hate and harassment that can, and has, driven people to suicide on other occasions. That's way more serious and understandable, and playing that down as just someone being "anti free speech" as being part of the problem.

Post reply on HN