Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tokio 1.0 – async runtime for Rust

tokio.rs

Post reply on HN
Print view View original

81–90 of 422 posts

Re: Tokio 1.0 – async runtime for Rust

#81

Post by ibraheemdev »

rossmohax wrote: post #56
ibraheemdev wrote: post #39

Earlier quoted context omitted.

async-std [0] is pretty widely used as well. [0]: https://github.com/async-rs/async-std Most libraries can be used with different runtimes. Hyper for example, which uses Tokio by default, can be configured to use an async-std executor.

Can't find async-std feature here: https://github.com/hyperium/hyper/blob/master/Cargo.toml do you have an example? Either way, "can be configured" means that custom code for each runtime must be written, it is not like lets say "Futures", which can be used generically.

Here is an example: https://github.com/async-rs/async-std-hyper/blob/master/READ...

You do have to write a ~50 loc compat layer. However, most of the compat layer is due to the fact that tokio's `AsyncRead` and `AsyncWrite` are different from the standard futures crate, which may change in the future [0]. After that, you just have to implement `hyper::Executor` for async-std's `spawn`, and `hyper::Accept` for async-std's `TcpListener`.

Of course, it is not as generic as "Futures", but it is relatively simple to do. As @steveklabnik mentioned above:

> There's a few points here that still need some interop work. The intention is to fix that, but it's non-trivial. We'll get there.

[0]: https://github.com/tokio-rs/tokio/issues/2716

Re: Tokio 1.0 – async runtime for Rust

#82

Post by jayd16 »

simias wrote: post #77

I don't really get these modern async APIs. In languages like Javascript I thought they only made sense because JS interpreters are (historically) single-threaded, so you really have no choice but async to express some concepts. Fine. But in Rust you can just spawn threads, share data through channels or mutexes, use OS-provided async IO primitives to poll file descriptors and do event-driven programming etc... I tri…

Maybe its a matter of taste but I find async styles much easier to read than event driven coding.

Re: Tokio 1.0 – async runtime for Rust

#83

Post by artursapek »

simias wrote: post #77

I don't really get these modern async APIs. In languages like Javascript I thought they only made sense because JS interpreters are (historically) single-threaded, so you really have no choice but async to express some concepts. Fine. But in Rust you can just spawn threads, share data through channels or mutexes, use OS-provided async IO primitives to poll file descriptors and do event-driven programming etc... I tri…

It's syntactic sugar that makes code a lot easier to reason about.

Re: Tokio 1.0 – async runtime for Rust

#84

Post by xucheng »

simias wrote: post #77

I don't really get these modern async APIs. In languages like Javascript I thought they only made sense because JS interpreters are (historically) single-threaded, so you really have no choice but async to express some concepts. Fine. But in Rust you can just spawn threads, share data through channels or mutexes, use OS-provided async IO primitives to poll file descriptors and do event-driven programming etc... I tri…

In a sense, the async API allows you to create green threads. Comparing with the normal threads, which rely on OS schedule and introduce context switches, green threads allow tasks actively yielding the control. This for example can be used to run multiple IO tasks concurrently all in one single OS thread.

See https://en.wikipedia.org/wiki/Green_threads

Re: Tokio 1.0 – async runtime for Rust

#85

Post by steveklabnik »

simias wrote: post #77

I don't really get these modern async APIs. In languages like Javascript I thought they only made sense because JS interpreters are (historically) single-threaded, so you really have no choice but async to express some concepts. Fine. But in Rust you can just spawn threads, share data through channels or mutexes, use OS-provided async IO primitives to poll file descriptors and do event-driven programming etc... I tri…

Async/await matters in Rust specifically because the borrow checker makes writing code without it difficult, inefficient, and unergonomic: http://aturon.github.io/tech/2018/04/24/async-borrowing/ (note that some of the details have changed here, but the thrust of it is very much the same.)

That said, if you can get your job done without this stuff, that's fine too, but the reasons it was pursued specifically involve the above.

Re: Tokio 1.0 – async runtime for Rust

#86

Post by steveklabnik »

xucheng wrote: post #75

I wonder whether there is any ongoing effort to unify the ecosystem between different runtimes. Specially considering that Tokio and futures (by extension async-std) implement their own Async* traits, it seems that it becomes even harder to write runtime agnostic libraries. It would be nice if these fundamental traits were part of rust std library.

This is mentioned downthread, but yes, the intention is still for that to happen. There's more work to be done here.

Re: Tokio 1.0 – async runtime for Rust

#87

Post by jayd16 »

dragonwriter wrote: post #71
Xevi wrote: post #33

Earlier quoted context omitted.

C#/.NET has all of this already. You don't have to import anything else to use async/await.

[deleted: man, was that a dumb comment]

No I think you're mistaken. You can rewrite pretty much every part of the system. You can write your own synchronization, you can write your own scheduling, you can write custom awaiter implementations. Its very pluggable.

You might be able to argue that its even more pluggable than Tokio because the system has the concept of current context and attaching a task to it. Library code can use your custom scheduler.

You can even throw away the Task type and create your own future type that works with the async/await syntax but of course no library would be able to pick that up.

Re: Tokio 1.0 – async runtime for Rust

#88

Post by sanxiyn »

jayd16 wrote: post #82
simias wrote: post #77

I don't really get these modern async APIs. In languages like Javascript I thought they only made sense because JS interpreters are (historically) single-threaded, so you really have no choice but async to express some concepts. Fine. But in Rust you can just spawn threads, share data through channels or mutexes, use OS-provided async IO primitives to poll file descriptors and do event-driven programming etc... I tri…

Maybe its a matter of taste but I find async styles much easier to read than event driven coding.

Comparison is to threads, not to event callbacks. Threads are (at least in Rust) even easier to read than async.

Re: Tokio 1.0 – async runtime for Rust

#89

Post by steveklabnik »

jayd16 wrote: post #79
rossmohax wrote: post #37

It is unfortunate, that libraries have to be coded against specific runtime and not generically. There is tokio and there is smol (likely discontinued, since author left rust), maybe other runtimes will emerge, but whole ecosystem is already tied to tokio.

If core rust provides an interface for async/await why does usage of it tie you to a specific runtime? Whats the point of that?

Usage of it, on its own, does not tie you to a specific runtime.

Using runtime-specific features and APIs ties you to a specific runtime.

Re: Tokio 1.0 – async runtime for Rust

#90

Post by sanxiyn »

xucheng wrote: post #84
simias wrote: post #77

I don't really get these modern async APIs. In languages like Javascript I thought they only made sense because JS interpreters are (historically) single-threaded, so you really have no choice but async to express some concepts. Fine. But in Rust you can just spawn threads, share data through channels or mutexes, use OS-provided async IO primitives to poll file descriptors and do event-driven programming etc... I tri…

In a sense, the async API allows you to create green threads. Comparing with the normal threads, which rely on OS schedule and introduce context switches, green threads allow tasks actively yielding the control. This for example can be used to run multiple IO tasks concurrently all in one single OS thread. See https://en.wikipedia.org/wiki/Green_threads

Yes, but why would you want that? Using OS threads is better in most cases.
Post reply on HN