Hacker News Reader

Comment by cmckn | Hacker News Reader

I'm a Rust noob, and I don't understand the relationship of Tokio and the language's async/await syntax. Is there a "reference implementation" of the runtime? Is Tokio or another runtime required for those keywords to do anything?

I also found this blurb from the website to be confusing:

> Zero-cost abstractions Tokio's run-time model adds no overhead compared to an equivalent system written entirely by hand.

This sounds like Tokio's impl is comparable to other impl's of "the same" system, but how does it compare to "naked Rust"?

View on HN

> and I don't understand the relationship of Tokio and the language's async/await syntax.

One of the surprising things with rust here, is that it define only the syntax and some bare traits AND ALLOW TO PLUG ANY RUNTIME.

This mean you can "swap" runtime implementations and even build your own.

One recent example is:

https://www.reddit.com/r/rust/comments/g917ad/smol_stjepang_...

This is in contrast with Go/Erlang/.NET, etc where the runtime for it is made for you, but can't be changed. This is cool where things are mostly fine all the time, but rust being a SYSTEM lang allow this is neat (example: Embebed scenarios where a regular runtime is too heavy).

Note: This template show in other places, where for example you can swap the allocator or the (default) hash function.

I should also note, for balance, that this isn't perfect today. There are still some missing bits to make it truly "plug anything anywhere," but it's pretty close.

The main thing I don't understand about Rust's async/await situation is how it's not very inefficient on the CPU given that it fundamentally uses polling? https://doc.rust-lang.org/std/future/trait.Future.html

The model is very similar to how epoll works. The executor does not poll futures in a loop. Between polls, the executor waits for a readiness notification.

If `Future::poll` returns Pending, once it becomes ready to do more work, it notifies the executor, the executor then schedules the future to be polled again.

I suspect that a big part of the design of this api (and why it take time) was exactly to be as performant as possible.

The compiler desugar the async/await to state machines and that is melted away by regular means. Also, the quality of the runtime elected must take some credit.

It doesn't poll all the time. The context parameter contains a walker, and you have to tell the executor to wake you up using that waker when you are ready to continue.

Was Python the first language to do async that way? I know within the Python ecosystem you've got asyncio, Trio, Curio, etc.

So it's sort of like the javax API?

Active Oberon, Ada and C++ are system languages and have default implementations as part of the standard.

I don't know about the others, but C++ don't have a default implementation as part of the standard. If you want an event loop, you need to use one of the many libraries that provide one.

C++20 surely has one.

No, it hasn't.

Actually C++20 comes with only the minimal support for coroutines in the std library. If you want to do anything useful, you need to implement a promise type yourself which is very hard to do without using one library that does that.

From the looks of it, and what I am already able to do with Visual C++ I bet it still is more functional than what Rust currently offers.

And that I won't need to rewrite it when I try out the same code with another C++20 compiler.

"system" here is intended to refer to the application using tokio, i.e. if you got rid of tokio and did everything by hand you wouldn't be able to make your application faster.

Ahhh; thank you!

The standard library currently only contains what is necessary to define _what_ a Future is. It contains no tools for actually executing them, and this is the role of Tokio.

Very cool, so I can choose my own impl. Does Tokio have a true competitor today? From my cursory look at some projects, Tokio shows up everywhere.

There are some other executors too such as async-std, smol and bastion, but Tokio is the one with the largest ecosystem.

There's even been experiments with binding futures to glib or various GUI event loops!

I have also heard some talk on building executors for embedded devices where you can't allocate memory on the heap.

Yes, this was a big constraint on the design of the overall system; there's been a couple that have popped up.

Reply on news.ycombinator.com