4 ms·

It's exciting to see so many systems programming languages implement async/await. For a further comparison, Nim works in the same way as Zig when it comes to e

by dom96 8y ago

It's exciting to see so many systems programming languages implement async/await. For a further comparison, Nim works in the same way as Zig when it comes to eager evaluation. Something that I'm particularly proud of when it comes to Nim's async/await implementation is that everything, right down to the macro which defines what `await` means, is implemented in the standard library. The compiler only implements the coroutines. This means that the language isn't bloated by this extra feature and makes it much easier for developers to implement their own async/await. I believe there was talk to do the same in Rust, but for some reason the developers decided to implement it in the compiler instead.

steveklabnik 8y ago
Async blocks require a keyword to be unambiguous with a struct constructor.
aidanhs 8y ago
Can you clarify what youre referring to with "decided to implement it in the compiler instead", be it from this blog post or elsewhere? Clearly you need coroutines in the compiler, and the way Rust treats ownership means pinning is needed in some way (I've not been following closely so don't know if this is in libstd or a language-level feature), but the rest (according to this post) seems to be going in libstd so you can write your own if you want.
- steveklabnik 8y ago
  Pinning is almost entirely a library feature; it does use the unstable “auto traits” functionality of the language, so it’s a bit special in that regard. But it’s provided by the standard library.
- dom96 8y ago
  > Can you clarify what youre referring to with "decided to implement it in the compiler instead" I'm referring specifically to the async/await syntax. Coroutines probably need to be implemented in the compiler, sure, but the actual async/await can be implemented with metaprogramming.
skybrian 8y ago
As another comparison, Dart started out delaying execution of async functions and then switched to eager in Dart 2: https://groups.google.com/forum/#!topic/flutter-dev/3R9qhjNGZk4 https://groups.google.com/forum/#!topic/flutter-dev/3R9qhjNG...
withoutboats 8y ago
We did implement it out of tree at first. [0] Because Rust requires annotations on macros to distinguish them from built in syntax, they are less ergonomic to use. In general, we believe in adopting a path of beginning as an out-of-tree macro, and then deciding to elevate that to first class syntax if its clear that they will be extremely commonly used. [0]: https://github.com/alexcrichton/futures-await https://github.com/alexcrichton/futures-await

by dom96 8y ago

steveklabnik 8y ago

Async blocks require a keyword to be unambiguous with a struct constructor.

aidanhs 8y ago

Can you clarify what youre referring to with "decided to implement it in the compiler instead", be it from this blog post or elsewhere? Clearly you need coroutines in the compiler, and the way Rust treats ownership means pinning is needed in some way (I've not been following closely so don't know if this is in libstd or a language-level feature), but the rest (according to this post) seems to be going in libstd so you can write your own if you want.

steveklabnik 8y ago
Pinning is almost entirely a library feature; it does use the unstable “auto traits” functionality of the language, so it’s a bit special in that regard. But it’s provided by the standard library.
dom96 8y ago
> Can you clarify what youre referring to with "decided to implement it in the compiler instead" I'm referring specifically to the async/await syntax. Coroutines probably need to be implemented in the compiler, sure, but the actual async/await can be implemented with metaprogramming.

skybrian 8y ago

As another comparison, Dart started out delaying execution of async functions and then switched to eager in Dart 2: https://groups.google.com/forum/#!topic/flutter-dev/3R9qhjNGZk4 https://groups.google.com/forum/#!topic/flutter-dev/3R9qhjNG...

withoutboats 8y ago

We did implement it out of tree at first. [0] Because Rust requires annotations on macros to distinguish them from built in syntax, they are less ergonomic to use. In general, we believe in adopting a path of beginning as an out-of-tree macro, and then deciding to elevate that to first class syntax if its clear that they will be extremely commonly used. [0]: https://github.com/alexcrichton/futures-await https://github.com/alexcrichton/futures-await