Maybe Rust isn’t a good tool for massively concurrent, userspace software

Post by riku_iki » Fri, Sep 08, 2023, 10:08 PM UTC

dilippkumar wrote: post #321

riku_iki wrote: post #273

Earlier quoted context omitted.

> In terms of performance, ARC offers massive benefits but it also has big disadvantage, that it communicates to actual malloc for memory management, which is usually much less performant than GC from various reasons.

> which is usually much less performant than GC from various reasons. Can you elaborate? I've seen a couple of malloc implementations, and in all of them, free() is a cheap operation. It usually involves setting a bit somewhere and potentially merging with an adjacent free block if available/appropriate. malloc() is the expensive call, but I don't see how a GC system can get around the same costs for similar reasons.…

Post by veber-alex » Fri, Sep 08, 2023, 10:11 PM UTC

vore wrote: post #238

saghm wrote: post #227

Earlier quoted context omitted.

You're not wrong, but I don't really see the problem? Even well before async Rust, closures worked the same way with not being able to specify a concrete type, and `impl Trait` syntax didn't even exist for a while. Annotating local variable types is a way to fix certain things that would otherwise be ambiguous; it's a means to an end, only an end itself.

Ah that's true, but I think it ends up hairier when you combine the two together and have closures that are async, e.g.: let x = || -> i32 { 1 }; // fine let x = || -> impl Future { async { 1 } }; // error: `impl Trait` only allowed in function and inherent method return types, not in closure return types Unless I'm missing something, sometimes you do have to name the return type of an async closure if it's returning…

    let x = || async {
        let file = std::fs::read_to_string("foo.txt")?;
        Ok::>(file)
    };

Post by skitter » Fri, Sep 08, 2023, 10:15 PM UTC

Animats wrote: post #133

lordnacho wrote: post #9

I find myself in this weird corner when it comes to async rust. The guy's got a point in that doing a bunch of Arc, RwLock, and general sharing of state is going to get messy. Especially once you are sprinkling 'static all over the place, it infects everything, much like colored functions. I did this whole thing once back when I was starting off where I would Arc stuff, and try to be smart about borrow lifetimes. Tot…

That was the argument for Go. But Go is not used that way. People still share and lock stuff in Go. Go is only safe for race conditions that break the memory model, not all race conditions, as Rust is.

Post by the_af » Fri, Sep 08, 2023, 10:19 PM UTC

jerf wrote: post #153

vilunov wrote: post #112

Earlier quoted context omitted.

I want colored functions. I want to know which code is running synchronously and which doesn't, which raises errors and which doesn't. Color is just a description of the function's properties (and effects) and how it's compatible with other colors. There is also nothing fundamentally bad with cooperative scheduling in scope of a single process.

I got into programming in the 1990s. At that point in time, there was still a large contingent of programmers loudly insisting they needed assembly language to do everything. And to be clear, I mean, everything. Not "Yeah, I can't really bring up an OS without a bit of specialized assembly" but "every programmer should write every program in assembly". The vast majority of them were already wrong. They only got more…

Post by veber-alex » Fri, Sep 08, 2023, 10:22 PM UTC

likeabbas wrote: post #298

Pauan wrote: post #213

Earlier quoted context omitted.

No, tokio does not require your Futures to be thread-safe. Every executor (including tokio) provides a `spawn_local` function that spawns Futures on the current thread, so they don't need to be Send: https://docs.rs/tokio/1.32.0/tokio/task/fn.spawn_local.html I have used Rust async extensively, and it works great. I consider Rust's Future system to be superior to JS Promises.

So you’re stuck choosing a single CPU or having to write send and sync everywhere. There’s a lot of use cases where you would want a thread-per-core model like Glommio to take advantage of multiple cores while still being able to write code like it’s a single thread. > I have used Rust async extensively, and it works great. I consider Rust's Future system to be superior to JS Promises. Sure, but it’s a major headache…