The work on Rust in the Linux kernel doesn't include the standard library, and even if it did, having an executor around doesn't prevent you from creating and using a different one.
I think they are pointing out that because the Rust design has decoupled the functionality from the implementation, these kind of replacements are even possible in the first place.
Of course, if you use an alternative executor there are large swaths of the (non-std) async ecosystem that are not available to you (thinking of anything like relying on a tokio::timer::Delay as an example). But as you point out Rust in the Linux kernel already doesn't rely on the std, so they wouldn't even begin to imagine to use an off the shelf crate and expect it to work unmodified for their use case. I just think it is worth pointing out that this is a constraint we currently have.
Right, yes: if we had a design that built a single executor into the language or we had a runtime that included it, you wouldn't be able to replace that as easily. Because executors are, at most, a library mechanism, you can always replace them or run more than one.
Thank you, you're too kind. I don't know how much that experience of "make the compiler try to talk to a human in a way they can understand it" translates to other parts of life, though :)
It doesn't in rust but in many other languages there would have been a single blessed async library and trying to use anything else would have been very painful. The fact that rust doesn't particularly force the use of it's standard runtime is key to why rust is useful for kernel work.
Yeah, but I think what they're getting at is that Rust could provide a standard executor in the library and also be modular enough that you can use whichever one you want. The questions are orthogonal
