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

141–150 of 206 posts

Re: Rust for Filesystems

#141

Post by brigadier132 »

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.

How do you imagine async works otherwise? Also, in case you misunderstand how polling works in practice in rust, it's not polling in the traditional web development sense where it polls every 5 ms to check if a future is completed (although you can do this if you want to for some reason). There are typically "wakers" that are "awoken" by the os when data is ready and when they are "awoken" then they poll. And since they are only awoken by the OS when the information is ready it really never has to poll more than once unless there are multiple bundled futures.

Re: Rust for Filesystems

#142

Post by 0cf8612b2e1e »

BiteCode_dev wrote: post #125
nickparker wrote: post #118

Earlier quoted context omitted.

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

I am definitely of the opinion we need to rush away from C. Rust, Go, Zig, etc does not matter, but anything which can catch some of the repeated mistakes that squishy humans keep repeating.

That being said, the file system is one of those infrastructure bits where you cannot make a mistake. Introduce a memory corruption bug leading to crashes every Thursday? Whatever. Total loss of data for 0.1% of users during a leap year at a total eclipse? Apocalypse.

There is no amount of being too careful when interfacing with storage. C may have a lot of foibles, but it is the devil we know.

Re: Rust for Filesystems

#143

Post by foldr »

weinzierl wrote: post #12
sanxiyn wrote: post #9

Earlier quoted context omitted.

Note that unsafe blocks don't have limited blast radius. Blast that can be caused by a single incorrect unsafe block is unlimited, at least in theory. (In practice there could be correlation of amount of incorrectness to effect, but same also could be said about C undefined behavior.) Unsafe blocks limit amount you need to get correct, but you need to get all of them correct. It is not a blast limiter.

Yes, they don't contain the blast, but they limit the places where a bomb can be, and that is their worth.

Generally speaking yes, but there could be a logic error somewhere in safe code that causes an unsafe block to do something it shouldn’t. For example, a safe function that is expected to return an integer less than n is called within an unsafe block to obtain an index, but the return value isn’t actually less than n. In that case the ‘bomb’ may be in the unsafe block, but the bug is in the safe code.

Re: Rust for Filesystems

#144

Post by commodoreboxer »

varjag wrote: post #126
lambda wrote: post #119

Earlier quoted context omitted.

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.

It's on par with C++, too. In C++ you need an `extern "C"`, because C++ linkage isn't guaranteed to be the same as C linkage. You can get away with wrapping that around it in a preprocessor conditional, but that's not all that much easier than Rust's bindgen.

A lot of C to C++ interop is actually done wrong without knowing it. Throwing a C++ static function as a callback into a C function usually works, but it's not technically correct because the linkage isn't guaranteed to be the same without an extern "C". In practice, it usually is the same, but this is implementation-defined, and C++ could use a different calling convention from C (e.g. cdecl vs fastcall vs stdcall. The Borland C++ compiler uses fastcall by default for C++ functions, which will make them illegal callbacks for C functions).

The major difference between Objective-C and C++'s C interop and other languages is the lack of the preprocessor. Macros will just work because they use the same preprocessor. That's really not easy to paper over in other languages that can't speak the C preprocessor.

Re: Rust for Filesystems

#145

Post by mcronce »

varjag wrote: post #134
gizmo686 wrote: post #131

Earlier quoted context omitted.

... And? Most languages make C interop simple.

They quickly become unwieldy on non-trivial APIs, with hundreds of definitions across dozens of files and with macros to boot. Naturally people would still get the job done but it's beyond simple.

That's what bindgen is for, as was mentioned in the original comment you replied to.

Re: Rust for Filesystems

#146

Post by im3w1l »

erdii wrote: post #37
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.

In this specific case complaining about "politics" gets the sour by-taste of enabling (or at least not condoning) harrasment to the point of single folks taking their own lifes over it. Why?! Even if you're not sure what to think about the queer movement; even if you have already made up your mind about the queer movement and oppose their ideas or some of them; I refuse to believe that any single person would not wan…

To me, you have to distinguish between harassment directed at a person, and on the other hand discussion about a person.

It is not possible to use hacker news to send messages to someones email. It is not even possible to send a dm to another hacker news user. You could potentially imagine hacker news being used to organize harassment of someone, but I have never seen either accusations or evidence of such a thing.

So then we have established, that since harassment directed at them is impossible, the issue they have is that people on hacker news write bad things about them.

Next, those things seem to often be flagged or downvoted, reducing exposure. But that is apparently not enough, because they can be found on google. So here we arrive at the core issue. There is content on Google about this person, that they would rather not be on Google. This is the complaint. So this person is basically saying that if there is unfavorable coverage of them findable on google, that is harassment, and it needs to go. If it isn't purged it's bullying that could lead to suicide.

This is a very ambitious "landgrab" if you will, and it starts to seriously infringe on other peoples rights.

It's similar in that manner to other things like "stop terrorism" or "think of the children". Yes clearly harassment is bad, and terrorism is bad, and pedophiles are no good. But we can't completely give up on our freedoms because of that.

Re: Rust for Filesystems

#147

Post by mcronce »

yjftsjthsd-h wrote: post #135
jeroenhd wrote: post #70

Earlier quoted context omitted.

The author of the website details their issue with the way HN does moderation (which I can't say I disagree with, especially after HN intentionally disabled referrer headers for websites that take issue with HN). This only shows up if HN is in the referer URL. I wouldn't call it a rant, but rather a polite request for HN policy to change.

> I wouldn't call it a rant, but rather a polite request for HN policy to change. Which is made by blocking people with no ability to do anything about it.

What? All you need to do is resubmit the request without a Referer header. For me, using Firefox, this meant clicking in the address bar, changing nothing, and hitting enter.

That's hardly "no ability to do anything about it".

Re: Rust for Filesystems

#148

Post by DSMan195276 »

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…

> but still use the same functions for inode lifecycle management

I'm not an expert by any means but I'm somewhat knowledgeable, there's different functions that can be used to create inodes and then insert them into the cache. `iget_locked()` that's focused on here is a particular pattern of doing it, but not every FS uses that for one reason or another (or doesn't use it in every situation). Ex: FAT doesn't use it because the inode numbers get made-up and the FS maintains its own mapping of FAT position to inodes. There's then also file systems like `proc` which never cache their inode objects (I'm pretty sure that's the case, I don't claim to understand proc :P )

The inode objects themselves still have the same state flow regardless of where they come from, AFAIK, so from a consumer perspective the usage of the `inode` doesn't change. It's only the creation and internal handling of the inode objects by the FS layer that depends based on what the FS needs.

Re: Rust for Filesystems

#149

Post by Klonoar »

foldr wrote: post #143
weinzierl wrote: post #12

Earlier quoted context omitted.

Yes, they don't contain the blast, but they limit the places where a bomb can be, and that is their worth.

Generally speaking yes, but there could be a logic error somewhere in safe code that causes an unsafe block to do something it shouldn’t. For example, a safe function that is expected to return an integer less than n is called within an unsafe block to obtain an index, but the return value isn’t actually less than n. In that case the ‘bomb’ may be in the unsafe block, but the bug is in the safe code.

I cannot imagine writing a method to return a value less than n, and not verifying that constraint somewhere in the safe method.

Re: Rust for Filesystems

#150

Post by [deleted] »

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.

[deleted]
Post reply on HN