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

131–140 of 422 posts

Re: Tokio 1.0 – async runtime for Rust

#131

Post by austinshea »

sanxiyn wrote: post #106
ibraheemdev wrote: post #102

Earlier quoted context omitted.

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.

Parallelism is complicated, and it is valuable.

Re: Tokio 1.0 – async runtime for Rust

#132

Post by austinshea »

sanxiyn wrote: post #127
nemothekid wrote: post #123

Earlier quoted context omitted.

Web servers are the quintessential product of async. It’s no surprise that for an industry dominated by web titans spend a lot of time writing web servers and have a huge interest in asynchronous processing. The importance of a sync was cemented way back in 1999 with the c10k problem with nginx vs Apache.

Most people are not writing the next nginx. They are writing web application servers behind nginx.

This, merely, means that the web application code will hold back what Nginx is capable of serving.

Re: Tokio 1.0 – async runtime for Rust

#133

Post by ibraheemdev »

sanxiyn wrote: post #121
ksenzee wrote: post #112

Earlier quoted context omitted.

Shouldn't an HTTP request library make async available? HTTP is the textbook example for async.

It should, but it shouldn't be the default. Right now, reqwest is the default HTTP request library in Rust ecosystem, and async is mandatory for reqwest. This is a bad situation to be in.

> async is mandatory for reqwest

async is not mandatory for reqwest. It provides a blocking API as well.

> reqwest is the default HTTP request library in Rust ecosystem

There is no "default" libraries. There are popular HTTP clients other than reqwest that also provide blocking APIs such as isahc and ureq

Re: Tokio 1.0 – async runtime for Rust

#134

Post by akvadrako »

ernst_klim wrote: post #108
akvadrako wrote: post #94

Earlier quoted context omitted.

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…

> 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).

Marking functions for side-effects would be a good thing but it isn't what function coloring means in this context.

An async function and a normal function are semantically the same, they just have different syntaxes and you can't easily call one from another.

They can be both be either blocking or non-blocking, especially if they take other functions as arguments.

Re: Tokio 1.0 – async runtime for Rust

#135

Post by austinshea »

sanxiyn wrote: post #121
ksenzee wrote: post #112

Earlier quoted context omitted.

Shouldn't an HTTP request library make async available? HTTP is the textbook example for async.

It should, but it shouldn't be the default. Right now, reqwest is the default HTTP request library in Rust ecosystem, and async is mandatory for reqwest. This is a bad situation to be in.

Req west? The best.

Re: Tokio 1.0 – async runtime for Rust

#136

Post by ibraheemdev »

oblio wrote: post #126
varajelle wrote: post #114

Earlier quoted context omitted.

> Considering a normal-sized Linux server can handle a million threads without much trouble, it really seems like misplaced effort Seems like that would use a lot of memory for all the stacks

Based on this, the default value is 2MB: https://unix.stackexchange.com/questions/127602/default-stac... So that would mean a lot of memory for 1 million threads, 2TB of RAM. But you can change the default. With a 64k stack you'd use up ~68GB of RAM, which doesn't seem like a lot for 1 million threads and 1 million requests happening at the same time.

What "normal-sized Linux server" has 70GB of RAM?

Re: Tokio 1.0 – async runtime for Rust

#137

Post by jedisct1 »

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; async functions world best with other async functions while normal blocking functions work best with other blocking functions.

Not in Zig: https://kristoff.it/blog/zig-colorblind-async-await/

Re: Tokio 1.0 – async runtime for Rust

#138

Post by nialv7 »

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…

I don't quite understand why one would find async code hard to read.

Basically if you just ignore the async/await keyword, the code should read mostly the same as synchronous code (which is the point of the async/await effort).

Maybe you have a concrete example of convoluted async code?

Re: Tokio 1.0 – async runtime for Rust

#139

Post by sanxiyn »

ibraheemdev wrote: post #133
sanxiyn wrote: post #121

Earlier quoted context omitted.

It should, but it shouldn't be the default. Right now, reqwest is the default HTTP request library in Rust ecosystem, and async is mandatory for reqwest. This is a bad situation to be in.

> async is mandatory for reqwest async is not mandatory for reqwest. It provides a blocking API as well. > reqwest is the default HTTP request library in Rust ecosystem There is no "default" libraries. There are popular HTTP clients other than reqwest that also provide blocking APIs such as isahc and ureq

reqwest provides a blocking API, but reqwest also always depends on Tokio. A blocking API doesn't help when I don't want Tokio in my dependency tree at all.

I am using isahc, but that also doesn't help when (say) Rusoto AWS library pulls reqwest pulls Tokio pulls async.

Re: Tokio 1.0 – async runtime for Rust

#140

Post by nialv7 »

sanxiyn wrote: post #96
artursapek wrote: post #83

Earlier quoted context omitted.

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

Synchronous code is even easier to reason about than code using async syntax sugar.

No, multithreaded synchronous code is not easier to reason about than async. I think most would agree.
Post reply on HN