Like you, I think that’s sort of fine, because you can always roll your own. But it’s also kind of sad: one of the best things about the Rust ecosystem is that you can so effortlessly use a small crate in a way you really can’t in C++ (historically, maybe modules will finally improve this).
Mixing executors is approximately fatal, AFAICT.
You could have two executors with no problem.
What might cause issues is if code running on one executor needed close interaction with the other - such as running a task on the other executor.
Most of the time this is just avoided by using only one executor. But that's not the only way.
Even in a systems context I think it's pretty reasonable to want to either perform or receive a HTTP request, as soon as you do that in Rust you are funneled into Hyper or something built on top of it (like reqwest) and instantly are dependent on tokio/mio.
The very first example in the reqwest readme^1 has tokio attributes, async functions AND trait objects. It's impossible that a beginner attempting to use the language to do anything related to networking won't be guided into the async nightmare before they have even come to grips with the borrow checker.
https://docs.rs/reqwest/0.11.2/reqwest/blocking/index.html
(Maybe this uses async rust under the hood, but you don't have to care about it)
Yes! Using `sans-async` must NOT diminish our productivity in comparison with `async` counterpart.
> at some point, coding event loops became very natural/comfortable for me
In fact it is, I'm very happy with it too.
> one nice thing about rust's async/await is, you don't have to use it, and if you don't, you don't pay for it in any way.
You've said it!
That's because you're focusing on precisely the points where Rust has done better than Python, and conspicuously glossing over Python's asyncio debacle ... which looks exactly like Rust's.
In a nutshell, it works like this:
1. New syntax is introduced
2. We are told it's optional
3. The ecosystem adopts it, and it be comes de facto required
So right back at ya -- I am not convinced in the least by Rust's argumentation ;)
It's unclear to me how leadership can fix this. The cat is out of the bag, and the language must now contend with a second-order embedded syntax. Avoiding this becomes increasingly difficult as it is adopted in the ecosystem; just ask the C++ guys how they feel about exceptions.
one nice thing about rust's async/await is, you don't have to use it, and if you don't, you don't pay for it in any way. sure, I run into crates that expect me to bring in a giant runtime to make a http request or two (e.g. rusoto), but for the most part I have not had any issues productively using sans-async rust during the last few years.
so, if you don't like async/await, just don't use it! it doesn't change anything about the rest of rust.