A four year plan for async Rust

Post by no_wizard » Tue, Nov 07, 2023, 5:54 PM UTC

steveklabnik wrote: post #78

no_wizard wrote: post #64

Earlier quoted context omitted.

Thats red herring IMO. Sure, they're GC'd languages, but that does not preclude the fact that both of these approaches from a DX perspective are easier to work with, and that matters in language design. I didn't say we need goroutines or we need Loom style asynchronous primitives I am however pointing out, that they did a really good job of making async approachable and feel like you're writing the same code as you w…

> both of these approaches from a DX perspective are easier to work with, and that matters in language design. While you are right that DX matters, DX is not the only thing that exists. Design is about balancing constraints and tradeoffs. Rust has other design commitments that preclude using this design, before you even get to DX questions. (Furthermore not everyone agrees that these things are clearly better from a…

Post by jayd16 » Tue, Nov 07, 2023, 5:55 PM UTC

samus wrote: post #112

jayd16 wrote: post #59

Earlier quoted context omitted.

Async handles thread contexts better. Maybe I'm out of the loop but implicit blocking patterns haven't taken over gui programming just yet.

Loom is very new, and Java on the desktop is almost dead. Even though virtual threads could be useful for GUI programming, I don't expect significant innovation in that area. But the upcoming Structured Concurrency[0] and Scoped Values[1] JEPs make things hopefully easier. [0]: https://openjdk.org/jeps/462 [1]: https://openjdk.org/jeps/446

Post by insanitybit » Tue, Nov 07, 2023, 5:57 PM UTC

no_wizard wrote: post #102

insanitybit wrote: post #80

Earlier quoted context omitted.

> I didn't say we need goroutines or we need Loom style asynchronous primitives I am however pointing out, that they did a really good job of making async approachable and feel like you're writing the same code as you would in a traditional synchronous model. You created a dichotomy - languages with a native construct for async versus languages that provide this as libraries. But that dichotomy does not exist - both…

I agree, it should be taken really seriously. I think 4 years worth of a feature being out in the wild and in use is enough time to start having conversations about what went well and what didn't and how to address that. Its very clear to me, at least, that async in Rust is becoming more and more dependent on tokio. Most of the major async supporting crates support tokio and/or only leverage tokio. Just a cursory gla…

Post by kmeisthax » Tue, Nov 07, 2023, 5:58 PM UTC

andrewstuart wrote: post #14

I thought async and await were kind of logical builds on top of generators but this is saying rust has no generators. That’s how it works in javascript and as a commenter mentions in Python too, right?

Post by mplanchard » Tue, Nov 07, 2023, 5:58 PM UTC

wavemode wrote: post #108

dymk wrote: post #18

Earlier quoted context omitted.

> However, if a library uses async, you have little choice but to make your whole project async. This isn't true. I'm writing an application right now that is mostly sync, but has a small amount of async code in it. It's easy to spin up a tokio runtime which can run inline on the current thread. Then use it to evaluate a Future. tokio::runtime::Builder::new_current_thread().enable_all().build().unwrap().block_on(asyn…

The complexity of this code snippet almost seems satirical (though I do get the point you're making, and agree with you).

    use tokio::runtime::Builder;

    let runtime = Builder::new_current_thread()
        .enable_all()
        .build()?;

    runtime.block_on(async { println!("I'm async!"); });