Can someone tell me why tokio is so damn big and full of transitive dependencies :D?
You could also say that Tokio has a large and mature ecosystem surrounding it.
Tokio 1.0 – async runtime for Rust
111–120 of 422 posts
Re: Tokio 1.0 – async runtime for Rust
#112Earlier 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.
Shouldn't an HTTP request library make async available? HTTP is the textbook example for async.
Re: Tokio 1.0 – async runtime for Rust
#113Earlier 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…
Zig's "colorblind" async is very exciting for this reason: https://kristoff.it/blog/zig-colorblind-async-await/
I'm skimming your link trying to understand the design. It sounds like there is a global flag for whether the whole program is in evented or blocking mode?
> during compile-time, it’s possible to inspect if the overall program is in evented mode or not, and properly designed code might decide to move to a threaded model when in blocking mode, for example.
Re: Tokio 1.0 – async runtime for Rust
#114I 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…
> 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
Re: Tokio 1.0 – async runtime for Rust
#115Earlier quoted context omitted.
> 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.
Again, depends on if you're doing a lot of IO, especially if you want request-based IO parallelism.
It's worth mentioning that even if you're IO-bound at your DB, running an async application server now means you don't need to tie up a thread waiting on it. Memory usage aside, you more or less don't need to think about threads much, whereas a threadpool (one waiting on IO) is something you have to actively manage.
Re: Tokio 1.0 – async runtime for Rust
#116I 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…
[deleted]
Re: Tokio 1.0 – async runtime for Rust
#117Earlier quoted context omitted.
> 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.
[deleted]
Re: Tokio 1.0 – async runtime for Rust
#118Earlier quoted context omitted.
> 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
From what I've read, smol was created by its author and later on adopted by async-std. And, its author was in Tokio team, and later left and was in async-std team before he left and created smol. So smol was based on quite deep knowledge and experience in async.
Re: Tokio 1.0 – async runtime for Rust
#119Earlier 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.
If you think OS threads are "better" than async tasks, then use them. Other people want to use async, so they use it. Rust does not have a runtime and provides blocking APIs by default, but gives you the option to use async if you want to.
Re: Tokio 1.0 – async runtime for Rust
#120Earlier 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.
In fairness it's just the announcement of V1 of the library. There doesn't seem to me to be anyone promoting its use "everywhere".
On the other hand, there has been from day one a sort of hype around Rust's safety features, and an eagerness to promote any new library or framework written in Rust as a savior of programming. This library, as you note, will be used inappropriately (i.e. in contexts where it's not really necessary or reasonable to do) and lead to the worst kinds of bugs--those that lurk in complicated, difficult to understand code, and that are generally worse than any memory-related security vulnerability.