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.
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.