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, concurrency != parallelism.
Rust for Filesystems
171–180 of 206 posts
Re: Rust for Filesystems
#172Maybe 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…
Re: Rust for Filesystems
#173Earlier quoted context omitted.
[flagged]
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.
Why would anyone be upset with people sharing FLOW?
Re: Rust for Filesystems
#174Maybe 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…
https://github.com/tree-sitter/tree-sitter/blob/25c718918084...
Re: Rust for Filesystems
#175Earlier quoted context omitted.
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…
> Task.Yield() In c# you probably never call yield.
Re: Rust for Filesystems
#176Earlier quoted context omitted.
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…
> Task.Yield() In c# you probably never call yield.
Synchronous part of an async method in C# will run "inline". This means that should there be a computationally expensive or blocking code, a caller will not be able to proceed even if it doesn't await it immediately. For example:
var ptask = Primes.Calculate(n); // returns Task
// Do other things...right?
// Why are we stuck calculating the primes then?
Console.WriteLine("Started.");
In order for the .Calculate to be able to continue execution "elsewhere" in a free worker thread, it would have to yield.If a caller does not control .Calculate, the most common (and, sadly, frequently abused) solution is to simply do
var task = Task.Run(Primes.Calculate);
// Do something else
var text = string.Join(',', await task);
If a return signature of a delegate is also Task, the return type will be flattened - just a Task, but nonetheless the returned task will be a proxy that will complete once the original task completes. This successfully deals with badly behaved code.However, a better solution is to instead insert `Task.Yield()` to allow the caller to proceed and not be blocked, before continuing a long-running operation:
var ptask = Primes.Calculate(n); // returns Task
// Successfully prints the message
Console.WriteLine("Started.");
static async Task CalculatePrimes(int n)
{
await Task.Yield();
// Continue execution in a free worker thread
// If the caller immediately awaits us, most likely
// the caller's thread will end up doing so, as the
// continuation will be scheduled in the local queue,
// so it is unlikely for the work item to be stolen this
// quickly by another worker thread.
}Re: Rust for Filesystems
#177Earlier quoted context omitted.
That's not really "simple", it's on par with C FFI in about any other language (except C++), with same drawbacks.
How is that not simple? You just declare the function and then call it. I find it hard to imagine how it could be any more simple than that.
Re: Rust for Filesystems
#178Earlier 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…
"To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code."
"Safety measures make memory-unsafe languages slow"
Not saying Rust is the perfect solution to every problem, but it is definitely not an outlandish proposition to use it where it makes sense.
[1] https://security.googleblog.com/2022/12/memory-safe-language...
Re: Rust for Filesystems
#179Earlier quoted context omitted.
> 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 modera…
That sounds highly unlikely given the strict moderation on this site. So unless I see any evidence of it, I'll continue to assume otherwise. From what I can gather after looking at previous posts on Asahi Linux, as another commenter suggested, the author of that message is furious that some HN users were talking about a cartoon character alter ego that he uses to make video streams. Seems to me like he's overreacting…
Also, don't even start with the whole "Asahi Lina = Hector Martin" thing. You're literally echoing a Kiwi Farms thing and wondering why people accuse HN of having an overlap with that site?
Re: Rust for Filesystems
#180Maybe 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…
The point is that Rust can model invariants that C can't. You can call both ways, but if C is incapable of expressing what Rust can, that has important implications for the design of APIs which must be common to both.