Hacker News Reader

Comment by karmakaze | Hacker News Reader

Howdy, I'm not familiar with Tokio (or Rust much). Is Tokio sort of like Node for Rust (packaged as a library rather than executable)?

Or maybe more like Scala Akka Futures?

View on HN

Rust, as a systems language, doesn’t include a large runtime. It’s about the same size as C or C++‘s. But if you want to do asynchronous IO, you’ll need a runtime to manage all of your tasks. Rust’s approach is to include the interface to make a task (futures and async/await) into the language and standard library, but lets you import whatever runtime you’d like. This means that you can pull in one good for servers, one good for embedded, etc, and not be partitioned off from a chunk of the ecosystem. And folks who don’t need this functionality don’t have to pay for it.

Tokio is the oldest and most established of these runtimes, and is often the basis for web servers in Rust.

So yeah, “the node event loop as a library” is a decent way to think about it.

> Rust’s approach is to include the interface to make a task (futures and async/await) into the language and standard library, but lets you import whatever runtime you’d like.

Why is this better than having one official, standardized, optionally importable runtime?

Each point has something different:

1. official - it's not clear how this would be better; that is, the team is not likely to have more expertise in this space than others do

2. standardized - it is standardized, as I said, the interface is in the standard library

3. optionally importable - this is fine, of course, but so are these, so this attribute isn't really anything better or worse.

But I don't think this is the biggest strength of this approach, the big strength is that not everyone wants the same thing out of a runtime. The embedded runtimes work very differently than Tokio, for example. As the post talks about, it's assuming you're running on a many core machine; that assumption will not be true on a small embedded device. Others would develop other runtimes for other environments or for other specific needs, and we'd be back to the same state as today.

Closer to https://github.com/libuv/libuv compare to the description here: https://docs.rs/tokio/0.2.0-alpha.6/tokio/

libuv is a native C library that V8+node uses for async disk and network accesses

"Node for Rust" is a good way to think about it!

From what I know about Akka, I believe Akka does more than Tokio. For example, Akka manages a supervision tree. I believe Akka is trying to be more of an actor system where as Tokio is just trying to provide an asynchronous runtime for Rust.

Yes, it's confusing that Akka does both Futures and Actors (that it's well-known for). I've used and really liked Akka Futures so would probably much like Tokio.

Isn't node a single threaded event loop, while this and Go use multiple threads and queues to support multiple threads and processors?

They even went into that with the comparison with Seastar.

If this is better than Seastar, someone should start on porting ScyllaDB to Rust. Does Rust have a userspace TCPIP stack like Seastar? I think that is the other major advance Seastar uses for speedup.

Node (like browsers now) have Worker Threads though I haven't used the Node ones myself.

I don't know Scala Futures.. but I'd guess those.

Tokio is a runtime for managing Rust's Futures. Aka, the schedule that manages the various jobs (Futures) to run and etc.

I believe deno is using tokio under the hood

edit:

well, I guess not :)

https://github.com/denoland/deno/blob/master/core/Cargo.toml...

> A secure JavaScript/TypeScript runtime built with V8, Rust, and Tokio

Should they update their description? lol

https://github.com/denoland/deno/blob/4221b90c3febbe03a4b47e...

Reply on news.ycombinator.com