Live data from Hacker News

Tokio 1.0 – async runtime for Rust

tokio.rs

11–20 of 422 posts

Re: Tokio 1.0 – async runtime for Rust

#11
post #8

Can someone explain to a non-rustacean what Tokio introduces that's not part of Rust? It looks like Rust provides the async/await semantics, so I'm guessing this is an event loop and dispatching system?

The Rust language provides the async/await syntax, which can turn imperative code into Future objects, but to run those Future objects, you must repeatedly call their poll method. Tokio is the piece of code that calls that method. It does so in a manner such that futures are only polled if able to continue work, and not e.g. waiting for a timer. Besides that it provides lots of utilities for working with async code.

Would it be fair to compare this to Apple's Grand Central Dispatch a.k.a. libdispatch?

Re: Tokio 1.0 – async runtime for Rust

#12
post #9
post #8

Can someone explain to a non-rustacean what Tokio introduces that's not part of Rust? It looks like Rust provides the async/await semantics, so I'm guessing this is an event loop and dispatching system?

Replying to myself, I found this bit in the docs explaining how Tokio decorates the main: > An async fn is used as we want to enter an asynchronous context. However, asynchronous functions must be executed by a runtime. The runtime contains the asynchronous task scheduler, provides evented I/O, timers, etc.

To provide some more color on why this isn't built in, different runtimes provide different kinds of guarantees and performance profiles. A webapp has very different requirements than an embedded system, and so we don't want to provide a single runtime. The language contains the basic things needed for the ecosystem to exist, and interoperation points, and then leaves the rest to said ecosystem.

(Some of those interoperation points are still being worked out, so it's not perfect yet.)

Re: Tokio 1.0 – async runtime for Rust

#13
The first two paragraphs have a lot of guarantees. About stability of version 1.0, length of support for version 1.0 and how long until version 2.0 (at least). "We

"we are committing to providing a stable foundation..."

I am curious: Who is "we"? I have no priors, I really have no idea.

Re: Tokio 1.0 – async runtime for Rust

#15
post #13

The first two paragraphs have a lot of guarantees. About stability of version 1.0, length of support for version 1.0 and how long until version 2.0 (at least). "We "we are committing to providing a stable foundation..." I am curious: Who is "we"? I have no priors, I really have no idea.

The tokio maintainers and contributors

Re: Tokio 1.0 – async runtime for Rust

#17
post #13

The first two paragraphs have a lot of guarantees. About stability of version 1.0, length of support for version 1.0 and how long until version 2.0 (at least). "We "we are committing to providing a stable foundation..." I am curious: Who is "we"? I have no priors, I really have no idea.

"we" here refers to the Tokio team.

Re: Tokio 1.0 – async runtime for Rust

#18

Earlier quoted context omitted.

The Rust language provides the async/await syntax, which can turn imperative code into Future objects, but to run those Future objects, you must repeatedly call their poll method. Tokio is the piece of code that calls that method. It does so in a manner such that futures are only polled if able to continue work, and not e.g. waiting for a timer. Besides that it provides lots of utilities for working with async code.

Would it be fair to compare this to Apple's Grand Central Dispatch a.k.a. libdispatch?

To me it's kind of like the event loop of node.js (which I believe comes from libuv)?

Re: Tokio 1.0 – async runtime for Rust

#19

Earlier quoted context omitted.

The Rust language provides the async/await syntax, which can turn imperative code into Future objects, but to run those Future objects, you must repeatedly call their poll method. Tokio is the piece of code that calls that method. It does so in a manner such that futures are only polled if able to continue work, and not e.g. waiting for a timer. Besides that it provides lots of utilities for working with async code.

Would it be fair to compare this to Apple's Grand Central Dispatch a.k.a. libdispatch?

Yes, but it's strictly userspace. It's more like the concurrency primitives in the JVM. (Eg. work-stealing threadpool, timers, various abstractions over OS/kernel lower level async stuff.)
Post reply on HN