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

261–270 of 422 posts

Re: Tokio 1.0 – async runtime for Rust

#261

Post by nicoburns »

renewiltord wrote: post #245
jayy-lmao wrote: post #241

Earlier quoted context omitted.

I've got a few examples of simple web servers within my company, could backport some of it to a public example. Are you just looking to have something a bit like: ``` #[get('/todo')] async fn getTodos(...) -> impl Responder { let todos = reqwest.get('other-api/todos').await?; todos } ``` Obviously this code won't run, just want to gleam the gist of what you want from an example.

Hey, thank you for offering. Yes! Something minimal like that that doesn't use `reqwest::blocking` would be very helpful. If it could do the Error case too that would be cool. For Rocket, I have something like: #[get("/list/ ")] fn list_prospects(api_key: ApiKey, status: String) -> Result , Status> with a impl FromRequest for ApiKey But I couldn't quickly get an `async` piece in there so I just sucked it up and synce…

For Rocket you want to use the master branch which has async support. Then your request handler is an async function and you can just .await the future returned by reqwest.

Re: Tokio 1.0 – async runtime for Rust

#262

Post by nicoburns »

Xevi wrote: post #254
FridgeSeal wrote: post #207

Earlier quoted context omitted.

Async-std is still actively maintained and developed.

I was under the impression that it's based on Smol, but maybe I'm wrong.

It has separate maintainers (a whole team), who will continue to maintain the parts of smol they are using. Smol is relatively small and sinple.

Re: Tokio 1.0 – async runtime for Rust

#263

Post by slavik81 »

tijsvd wrote: post #146
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 had the same thing initially. The upside of async over a simple event loop is, in my experience, when things become less simple, and you end up with hard-to-read little state machines all over the place. With async, you can have your event loop, but the state machines are handled by the compiler. Code is like threaded code. That can be very convenient. Threads, obviously, accomplish the same thing, and arguably mor…

> A non-async function is "regular logic", it must complete without blocking.

What does 'blocking' mean? I would expect the definition of synchronous to be the exact opposite; i.e., a synchronous function must block the caller until the function has finished executing. For that matter, what is "regular logic"? The name implies there is some sort of "irregular logic" to contrast it with.

I get the feeling that the writing may be unclear because the concepts are themselves not well-defined.

Re: Tokio 1.0 – async runtime for Rust

#264

Post by nemothekid »

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.

>But for the rest of us, simple, blocking code will do just fine and save us a few headaches.

I understand your point, but if performance isn't a concern, why use Rust at all? If the intricacies of async is that much of a burden then Rust is probably not the right tool of the job.

Re: Tokio 1.0 – async runtime for Rust

#265

Post by renewiltord »

nicoburns wrote: post #261
renewiltord wrote: post #245

Earlier quoted context omitted.

Hey, thank you for offering. Yes! Something minimal like that that doesn't use `reqwest::blocking` would be very helpful. If it could do the Error case too that would be cool. For Rocket, I have something like: #[get("/list/ ")] fn list_prospects(api_key: ApiKey, status: String) -> Result , Status> with a impl FromRequest for ApiKey But I couldn't quickly get an `async` piece in there so I just sucked it up and synce…

For Rocket you want to use the master branch which has async support. Then your request handler is an async function and you can just .await the future returned by reqwest.

Oh, I must be behind. Should've kept up and tried it. Thank you!

Re: Tokio 1.0 – async runtime for Rust

#266

Post by [deleted] »

anarazel wrote: post #188
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.…

[deleted]

Re: Tokio 1.0 – async runtime for Rust

#267

Post by afavour »

sanxiyn wrote: post #239
afavour wrote: post #236

Earlier quoted context omitted.

I think the OP was using examples from a different ecosystems to demonstrate how such a consensus could be reached, if people wished for it.

I don't wish it. That sounds terrible to me.

I think your comments have made that clear. Which is fair enough. But I imagine others feel differently.

Re: Tokio 1.0 – async runtime for Rust

#268

Post by therein »

eropple wrote: post #243
sanxiyn wrote: post #139

Earlier quoted context omitted.

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.

Can you explain exactly what that library using Tokio internally exposes to you that's a problem? Because, as written, this sounds like a religious argument.

If you need to use (for the sake of the example) Rusoto, since it is based on tokio, you'll need to set up the Tokio executor or at least add a macro to your main for this to be done for you. I believe Rusoto actually would take care of this for you if you haven't done it yourself however friction arises when you were already using a different version of tokio and Rusoto is built against another.

Basically, it isn't entirely opaque to you how it is handled.

Re: Tokio 1.0 – async runtime for Rust

#269

Post by octoberfranklin »

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…

> portions of it are “just” synchronous API calls marshaled to a thread pool

That only happens when OS support is missing. As in, the OS does not support doing something asynchronously.

Once io_uring is implemented, there will be no more of these "portions" (at least not on Linux).

Re: Tokio 1.0 – async runtime for Rust

#270

Post by octoberfranklin »

pfraze wrote: post #8

Can someone explain to a non-rustacean what Tokio introduces that's not part of Rust? It looks like Rust provides the async/await semantics, so I'm guessing this is an event loop and dispatching system?

Tokio is basically the asynchronous standard I/O library for Rust.

Async/await are language features. Tokio is the library for using these to do I/O.

Rust has a really tiny standard library (by modern standards) and a very high standard for moving stuff into the standard library. Right now it has no "standard" asynchronous I/O library ("async-std" bequeathed that name on themselves; it doesn't ship with Rust).

Post reply on HN