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

101–110 of 422 posts

Re: Tokio 1.0 – async runtime for Rust

#101

Post by sanxiyn »

ibraheemdev wrote: post #93
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…

> when you have a huge number of very small tasks running concurrently because that's generally where OS-driven parallelism tends to suffer but is it such a common scenario Web servers are all about I/O and handling small tasks (requests), and are a perfect use case for asynchronous programming. > That sounds like premature optimization in many situations IMO Maybe in some cases... but then just don't use futures. Ru…

You may want async if you are writing the next nginx, but for most web application servers threading is perfectly fine.

Re: Tokio 1.0 – async runtime for Rust

#102

Post by ibraheemdev »

sanxiyn wrote: post #95
steveklabnik wrote: post #85

Earlier quoted context omitted.

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…

It all comes down to "is it such a common scenario?". Honest answer is no. async is for specialized situations and shouldn't be the default.

async is not the default. The standard library is 100% blocking, and Rust does not come with a runtime. However, async makes sense for a lot of people, which is why libraries like tokio and async-std are so popular.

Re: Tokio 1.0 – async runtime for Rust

#103

Post by sanxiyn »

akvadrako wrote: post #94
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…

There are some pretty bad usability problems with most async APIs too. One is they make your functions colored; async functions world best with other async functions while normal blocking functions work best with other blocking functions. They also introduce a lot of noise; putting async/await everywhere doesn't tell you anything interesting. Considering a normal-sized Linux server can handle a million threads withou…

Zig's "colorblind" async is very exciting for this reason: https://kristoff.it/blog/zig-colorblind-async-await/

Re: Tokio 1.0 – async runtime for Rust

#104

Post by steveklabnik »

jayd16 wrote: post #98
steveklabnik wrote: post #89

Earlier quoted context omitted.

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.

Is this just an artifact of the current work in progress state of things? Is it just a matter of the interface settling and library authors providing a bit more configuration options to become runtime agnostic?

I am not a super expert in all of the exact details, but my understanding is that generally, there are a few features that don't have a common trait yet. For example, "spawn me a new task." Once those traits exist, libraries can be written against them, and it'll all be agnostic. But you only even run into that kind of problem if you need that specific API in the first place.

Re: Tokio 1.0 – async runtime for Rust

#105

Post by 10000truths »

sanxiyn wrote: post #90
xucheng wrote: post #84

Earlier quoted context omitted.

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.

OS threads are preemptive and their scheduling is beyond your control, which introduces potential data races. Green threads allow for cooperative scheduling, which is much harder to mess up.

Re: Tokio 1.0 – async runtime for Rust

#106

Post by sanxiyn »

ibraheemdev wrote: post #102
sanxiyn wrote: post #95

Earlier quoted context omitted.

It all comes down to "is it such a common scenario?". Honest answer is no. async is for specialized situations and shouldn't be the default.

async is not the default. The standard library is 100% blocking, and Rust does not come with a runtime. However, async makes sense for a lot of people, which is why libraries like tokio and async-std are so popular.

async does not make sense for a lot of people and I am deeply worried by hype-driven popularity of Tokio and async-std in Rust.

Especially harmful is that common libraries like reqwest (for HTTP requests) pulls async.

Re: Tokio 1.0 – async runtime for Rust

#107

Post by knuthsat »

akvadrako wrote: post #94
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…

There are some pretty bad usability problems with most async APIs too. One is they make your functions colored; async functions world best with other async functions while normal blocking functions work best with other blocking functions. They also introduce a lot of noise; putting async/await everywhere doesn't tell you anything interesting. Considering a normal-sized Linux server can handle a million threads withou…

Yep, I was mind blown when I started using futures years ago with this coloring. But then I realized it’s all about types and monoids and applicatives and it started to get clear why I just can’t get the value out of a promise.

Re: Tokio 1.0 – async runtime for Rust

#108

Post by ernst_klim »

akvadrako wrote: post #94
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…

There are some pretty bad usability problems with most async APIs too. One is they make your functions colored; async functions world best with other async functions while normal blocking functions work best with other blocking functions. They also introduce a lot of noise; putting async/await everywhere doesn't tell you anything interesting. Considering a normal-sized Linux server can handle a million threads withou…

> One is they make your functions colored

This is definitely a good thing. All computations should me "marked" as total or effectful with various possible effects (blocking, async, nondeterministic, possibly non-terminating etc etc).

Reasoning about your program is hard when each computation is a blackbox possibly containing any side-effects which could cause unpredictable changes in the control flow and result in a completely incomprehensible way.

Async/await thing is indeed least sound and ergonomic way of doing this. Monads with monad transformers are a bit better. Algebraic effects are the best in terms of composability, ergonomics and mental overhead, but not here yet (though OCaml may be soon become the first industrial-grade language incorporating them [1])

[1] https://www.youtube.com/watch?v=z8SI7WBtlcA

Re: Tokio 1.0 – async runtime for Rust

#109

Post by n42 »

ibraheemdev wrote: post #73
lmkg wrote: post #69

Earlier quoted context omitted.

In very loose terms: Rust's async/await syntax defines an interface to async programming, not an implementation . Rust leaves the implementation, and thereby choice of concurrency strategy, to libraries. Tokio is such a library. There's at least one other popular one of note.

> There's at least one other popular one of note. The other popular runtimes are async-std [0] and smol [1]. [0]: https://github.com/async-rs/async-std [1]: https://github.com/smol-rs/smol

if I understand correctly, smol was created by the async-std folks, and async-std now uses it as its runtime

https://github.com/async-rs/async-std/pull/757

Re: Tokio 1.0 – async runtime for Rust

#110

Post by sanxiyn »

10000truths wrote: post #105
sanxiyn wrote: post #90

Earlier quoted context omitted.

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

OS threads are preemptive and their scheduling is beyond your control, which introduces potential data races. Green threads allow for cooperative scheduling, which is much harder to mess up.

This is moot. Rust prevents data races.
Post reply on HN