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

241–250 of 422 posts

Re: Tokio 1.0 – async runtime for Rust

#241

Post by jayy-lmao »

renewiltord wrote: post #183

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.

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.

Re: Tokio 1.0 – async runtime for Rust

#242

Post by coolreader18 »

btrask wrote: post #222
jen20 wrote: post #218

Earlier quoted context omitted.

> Why wouldn't you use threading? Because the C10^nK problem where n increases periodically is still a thing?

Green threads.

Those are async tasks

Or rather -- async tasks are as close as you can get to green threads in rust without a runtime that would impose overhead on every program

Re: Tokio 1.0 – async runtime for Rust

#243

Post by eropple »

sanxiyn wrote: post #139
ibraheemdev wrote: post #133

Earlier quoted context omitted.

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

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.

Re: Tokio 1.0 – async runtime for Rust

#244

Post by ibraheemdev »

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.

Are you aware that rouille and tiny_http (it's underlying HTTP implementation) have been unmaintained for a while now?

Re: Tokio 1.0 – async runtime for Rust

#245

Post by renewiltord »

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

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.

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 synced it all up since it's only backing a Retool dashboard so it isn't the end of the world.

So if the example is like:

    #[get('/todo')]
    fn get_todos() -> Result, Status>
      let todos = reqwest...
      Ok(todos)
or the equivalent in the web framework you have that would be hecka useful.

Re: Tokio 1.0 – async runtime for Rust

#246

Post by shmerl »

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 think async in this sense leverages concurrency, which isn't necessarily tied to parallelism.

I.e. parallelism means executing several tasks on different compute units (cores) at the same time (multiple threads abstraction). Concurrency simply means that you can execute several tasks over a period of time, but it can happen on the same compute unit (so even within one thread). Tasks could be interleaved and still all progress over time.

I guess some ideal usage is a combination of parallelism and concurrency, but using a separate thread for each task isn't necessarily the most optimal method, because threads have their gotchas like context switching and etc.

Re: Tokio 1.0 – async runtime for Rust

#247

Post by habitue »

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

> there didn't use to be AIO for buffered filesystem IO

Did they change libaio to work without O_DIRECT at some point? Or are you talking about io_uring for async file io?

Re: Tokio 1.0 – async runtime for Rust

#248

Post by [deleted] »

victor106 wrote: post #202
pvorb wrote: post #170

Earlier quoted context omitted.

In the Java world, project Loom[1] is hopefully going to end this situation of async code that is hard to use with blocking code. They introduce a concept called Virtual Threads (previously called Fibers, but they are still looking for the perfect name). This will allow for seamless interoperability between blocking and non-blocking code as everything in Java runs on a Thread and Virtual Threads are just a specializa…

Loom is going to be a game changer. Hopefully they release it soon.

[deleted]

Re: Tokio 1.0 – async runtime for Rust

#249

Post by 02020202 »

shepmaster wrote: post #23
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?

> rustafarian The community prefers the term "rustacean" to be as inclusive as possible. Please keep that in mind in the future.

you sound like a proper cunt

Re: Tokio 1.0 – async runtime for Rust

#250

Post by nicoburns »

pvorb wrote: post #233
nicoburns wrote: post #195

Earlier quoted context omitted.

Alternatively use async everywhere from the start and your headaches go away too. It's mixing blocking code with async code that causes issues.

Just do it if everyone in your team is comfortable with it. I'm just not as productive with async code.

Ah yeah, as someone whose first langauge is javascript where all IO and even things like timers are async, I forget that not everyone groks it. It's really not that complicated (at work we have junior devs with 6 months experience writing async code no problem), but I think there is a certain amount of unlearning that needs to be done if you're used to working with threaded code.
Post reply on HN