While I was chatting on reddit about
await syntax debate, I had a thought, that I wanted to write down, and maybe get shot down with some good arguments.
So, I’m doing node.js at dayjob, and
await feels very redundant there. I mean … what else are you going to do? Writing async code in JS is just a constant busywork of
awaiting everywhere for no benefit. Any time you have a
Future you can either return it upwards, combine, or await. While in JS these might be sometimes ambiguous syntax-wise, in Rust with a strong type system I don’t think it would be a problem. It seems to me that in Rust
await is mostly going to be here, compiler, I am aware that this can be a yieldpoint annotation busywork.
So the question is: are we (should we?) be really interested in a yieldpoints? I mean … you’ve already annotated the function/block as
async one, right? So it is marked as “this code can yield”. From the logical perspective yield-points at
await don’t really exist. It’s not like you can insert any code between future returning
Yield upward that
await generates. Even from a low-level/system-level code - having yield points explicitly marked does not seem that useful. Awaiting on a Future is just a blocking IO!
I’m aware that there is eg. a risk of holding a
Mutex locked over a yieldpoint. But is it that any different than holding it over any other IO? We don’t annotate reading from a socket with some
block keyword and we’re doing just fine, no? So what’s so different about awaiting on a
Future, which logically is just blocking on a IO?
So my thesis is - Because Rust is already so explicit and strongly typed, there’s no need for
await syntax and
Futures could auto-magically
await or something. That would kill a lot of redundant noise, without much downsides. It would also make converting code to async much easier, language easier to learn etc. Rust type-system guarantees that it’s not going to be a source of silly bugs, and “holding resources over a yieldpoint” is no different than “holding a resource over a blocking IO” which we already deal with just fine, and which can be a clippy lint or something of the same type (“locking over io”).