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

181–190 of 422 posts

Re: Tokio 1.0 – async runtime for Rust

#181

Post by pvorb »

pvorb wrote: post #156
austinshea wrote: post #132

Earlier quoted context omitted.

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

If you know that there will be 10k concurrent users in your application, go ahead and use async right from the start. But for the rest of us, simple, blocking code will do just fine and save us a few headaches.

And once you get to a limit, the alternative to rewriting everything in non-blocking code might be to put multiple instances of your blocking app on multiple VMs/k8s/whatever behind a load balancer.

Re: Tokio 1.0 – async runtime for Rust

#182

Post by steveklabnik »

btrask wrote: post #179
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…

Wait, what? What happened to "fearless concurrency"? I thought this was supposed to be one of the borrow checker's selling points! https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h...

I mean, it is, yes. That post is talking about threads. And the “fearless” name meant that it solves a lot of issues at compile time, which it still does in an async context.

Like any static analysis, it’s a give and take between making sure your analysis is sound, while still allowing useful programs.

Re: Tokio 1.0 – async runtime for Rust

#183

Post by renewiltord »

Always found these APIs a little hard to work with. For instance, if I tried to use `actix-web`, then using `reqwest` and `tokio` felt like pulling teeth.

If anyone's got minimal code lining up a web framework (any one, not stuck to actix) with some reqwest, I'd be thankful to look over it. Just some trivial stuff so I can add an API gateway that proxies a specific API.

Re: Tokio 1.0 – async runtime for Rust

#184

Post by pimeys »

olalonde wrote: post #30
steveklabnik wrote: post #12

Earlier quoted context omitted.

To provide some more color on why this isn't built in, different runtimes provide different kinds of guarantees and performance profiles. A webapp has very different requirements than an embedded system, and so we don't want to provide a single runtime. The language contains the basic things needed for the ecosystem to exist, and interoperation points, and then leaves the rest to said ecosystem. (Some of those intero…

When learning Rust a few months ago, I built a small client library for a REST API using reqwest (which uses Tokio). I then started writing a web app using Tide ( https://github.com/http-rs/tide ). I eventually realized that it would be difficult to use the library I had built earlier since Tide uses the async-std runtime rather than Tokio. That was very disappointing. Is there any plan to make it easier to write "ru…

You can make libraries runtime agnostic, but it requires a bit of design to get right. We tried our best with Tiberius[0], so you just need to provide an object implementing the AsyncRead and AsyncWrite traits from the futures crate, such as the TcpStream from async-std or tokio (using their compat module).

It is not perfect yet, and especially how tokio does not follow the rest of the ecosystem by implementing their own traits is kind of disappointing. We can work around that, but I was hoping they would fix this by version 1.0...

[0] https://github.com/prisma/tiberius

Re: Tokio 1.0 – async runtime for Rust

#185

Post by gabereiser »

p5a0u9l wrote: post #63
gabereiser wrote: post #47

Earlier quoted context omitted.

tokio is to rust what asyncio is to Python.

except say asyncio is pet of standard python

and tokio is pet of rust... I don’t see the value of this argument. Tokio is known as being THE async executor in rust. Asyncio being THE executor in Python. In other languages there’s a number of frameworks to choose from. In this comparison there really is only one.

Re: Tokio 1.0 – async runtime for Rust

#186

Post by sanxiyn »

Xevi wrote: post #169
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.

Woah, I didn't know about that. Does this mean Rust only has one maintained runtime now? Namely Tokio.

I think it's rather that smol is "complete" and doesn't need much maintenance.

Re: Tokio 1.0 – async runtime for Rust

#187

Post by timClicks »

btrask wrote: post #179
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…

Wait, what? What happened to "fearless concurrency"? I thought this was supposed to be one of the borrow checker's selling points! https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h...

It's still fearless, as in you don't need to worry that you might create data races, but can be clunky to write in some cases.

Re: Tokio 1.0 – async runtime for Rust

#188

Post by anarazel »

ComputerGuru wrote: post #180

One of the issues I have with the rust async story is that colored functions require (at least the way they’re handled in rust and similar languages) a separate standard library (Microsoft really outdid themselves providing a synchronous and asynchronous version of the BCL when they shipped async support, but that was also largely made possible by the fact that the underlying OS APIs were all fairly asynchronous at t…

> For those that don’t know, on Linux there is^H^H was really no such thing as properly async file system access (eg libc faked it in a similar fashion for aio)

That's not quite right - there didn't use to be AIO for buffered filesystem IO and for most operations beyond read/write.

But unbuffered reads/writes have been doable asynchronously for quite a long time, via io_submit/libaio. Without falling back to threads.

The restrictions around that can be onerous (e.g. one needs to be careful to not extend file sizes, or risk falling back to synchronous operation).

Re: Tokio 1.0 – async runtime for Rust

#189

Post by pvorb »

sanxiyn wrote: post #172
efaref wrote: post #147

Earlier quoted context omitted.

How many threads can you spawn before the system grinds to a halt? If you're processing thousands of requests per second and each request gets its own thread then you will start to queue on thread spawning. Don't forget that each thread gets its own stack taking up megabytes of memory. The async concept has been used for decades in pretty much every product I've worked on professionally, from enterprise raid controll…

rouille (my Rust web framework of choice) spawns threads each request, and it handles thousands of requests per second just fine. Computers are fast, and Rust doesn't slow down your computer. If you can't handle thousands of requests per second with thread per request, that's more about your software stack, not about threading. I guess it was different in the past when computers were slow. I can believee that.

And once starting and stopping threads adds to much delay to your request processing, there could be a thread pool that grows as needed and which will reuse threads that haven't been closed yet.

This mechanism is implemented by Apache httpd, Tomcat and pretty much every classic application server.

Re: Tokio 1.0 – async runtime for Rust

#190

Post by pvorb »

nialv7 wrote: post #138
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?

While it might not be that hard to read, it can certainly be harder to reason about.
Post reply on HN