4 ms·
This is only temporary. It’s because the standard library hasn’t exposed interfaces for everything in async land just yet. It’s not a trivial problem, but it’
by yazaddaruvala 4y ago
This is only temporary.
It’s because the standard library hasn’t exposed interfaces for everything in async land just yet.
It’s not a trivial problem, but it’s mostly a matter of the std-lib’s developers being overly defensive of std. Which is a hindrance for many things in the medium term, but in the long term likely a good choice.
Although I wish they’d find a better balance between the chicken and egg problem for “we need production usage of the interfaces to validate them as standard” vs “we need standard interfaces so it’s ergonomic to use them in production”.
- lvass 4y agoAsync/await should be locked behind a compiler flag and not used by libraries that aren't experimental. Instead it already contaminated the entire ecosystem with to-be-deprecated dependencies that are hard to remove.
- aaaaaaaaaaab 4y agoYep. I can’t help but see this as a python2.7 vs python3 story in the long run…
- stormbrew 4y agoRust wouldn't be anywhere near where it is now if it had gated and blocked async like this. Maybe it would be 'better' in some abstract sense, but it'd be a better language almost no one would be using, like basically every other systems language that's attempted to do what rust is doing other than C++. And if it were gated like this, we wouldn't even know about these kinds of problems, because no one would be using it and we wouldn't see them in practice. If anything, rust does too much gating of features for too long. So many things have been sitting behind "needs stabilization" for years, living in a catch-22 of "we don't know if this is a good idea because no one uses it" vs. "no one uses it because using nightly is scary". I'm quite glad this one managed to escape that trap.