I agree that this is a problem, which is why "providing an abstraction layer for runtimes" is something that comes up often as a desired project, but if you zoom out I believe the choice to not have a baked in runtime was the right call. It allowed schedulers to experiment with their APIs and internals in a way that anything in the stdlib can't. It allowed for the existence of schedulers for embedded devices. You can write a keyboard firmware using async/await to deal with IO events! How cool is that?
Granted, if you're working in a single "vertical", like web services, this sounds like "useless gold plating", but precluding use cases like that one would go counter to Rust's goals. If Rust didn't care about the language scaling from embedded to HPC, then you could indeed have "Easy Rust" that erases a bunch of sharp edges of the language.
> Rust can do better here.
The team agrees. We're working on it. It was a major area of focus on 2021 and wg-async still exists and is making progress. Some things take time be finished because there's a lot to do, not enough people and they are just plain hard.
If Rust never wants to ship an async runtime, then fine. But in place of that there needs to be a clear standard async API that everything uses so that as a user I can just bring my own runtime as I please and not worry about dependencies shipping their own runtimes. The problem right now is that the api is provided by the runtime so everything ends up depending on some flavor of async standard functionality. As part of this async API, things like async variants of functions that block (in the commonly accepted definition of blocking, i.e. "sleep or do no work while waiting for an OS interrupt to wake them, so locks and I/O") need to be clearly defined as such so that the compiler can reassure me that if the code compiles then I'm not calling any blocking functions inappropriately. Part of that I'd think would also be an attribute or syntax that would be attached to the existing blocking stdlib functions so that calling code that eventually calls them from an async context could be flagged as an issue at compile time. These two things would solve a lot of the pain I'm telegraphing.
Anyway, I don't keep up day-to-day on Rust happenings. I'm just a user of the language who sometimes needs to dive into the issue tracker when I run into bumps. If all this stuff is being worked on then awesome, simply take my critique as validation that you're working on the right stuff. At the end of the day, though, my experience and feedback is driven by what's currently available to me, not what's in the works but hasn't shipped yet. And part of my critique is that it takes quite awhile for Rust to move on issues that really only exist because something was shipped in a partially completed state. Perhaps the community could be more aggressive with the notion of a version 2.0 and that would unlock changes that are really difficult and annoying and time consuming to make in a compatible way but would be much more palatable if allowed to break a few things here and there. It's great that we have nightly Rust, but perhaps it's about time for a rust-next where people can start staging breaking changes.
I agree that this is a problem, which is why "providing an abstraction layer for runtimes" is something that comes up often as a desired project, but if you zoom out I believe the choice to not have a baked in runtime was the right call. It allowed schedulers to experiment with their APIs and internals in a way that anything in the stdlib can't. It allowed for the existence of schedulers for embedded devices. You can write a keyboard firmware using async/await to deal with IO events! How cool is that?
Granted, if you're working in a single "vertical", like web services, this sounds like "useless gold plating", but precluding use cases like that one would go counter to Rust's goals. If Rust didn't care about the language scaling from embedded to HPC, then you could indeed have "Easy Rust" that erases a bunch of sharp edges of the language.
> Rust can do better here.
The team agrees. We're working on it. It was a major area of focus on 2021 and wg-async still exists and is making progress. Some things take time be finished because there's a lot to do, not enough people and they are just plain hard.