Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Async-std: an async port of the Rust standard library

async.rs

Post reply on HN
Print view View original

111–120 of 238 posts

Re: Async-std: an async port of the Rust standard library

#111

Post by staticassertion »

esotericn wrote: post #65
2bitencryption wrote: post #46

I must be dumb, because every time I dive into async/await, I feel like I reach an epiphany about how it works, and how to use it. Then a week later I read about it again and totally lost all understanding. What do I gain if I have code like this [0], which has a bunch of `.await?` in sequence? I know .await != join_thread(), but doesn't execution of the current scope of code halt while it waits for the future we are…

Right, that specific instance is essentially a single-threaded* application. Now imagine that you spawned a few hundred of them with JoinAll. Each would run, multiplexed within a single thread, with execution being passed at the await points. * anyone know the correct nomenclature for this? Single-coroutine?

Serial?

Re: Async-std: an async port of the Rust standard library

#112

Post by Argorak »

Arnavion wrote: post #105
mintplant wrote: post #99

How does this relate to Tokio [0]? Why should I choose this new library instead? [0] https://github.com/tokio-rs/tokio

If all you needed from tokio was tokio::net, then async-std could work as a replacement for raw TCP stuff. If you needed the higher-level stuff from tokio like codecs then you'd not have those. Also, anything from the tokio ecosystem like hyper would not work with async-std. Edit: I originally had a first paragraph which was wrong. I mistakenly thought std::net::TcpListener is supposed to impl Read / Write.

> async-std has the equivalent of std::net::TcpListener, however it does not appear to actually impl AsyncRead / AsyncWrite. So as of now you can't do anything with it. TcpStream does impl them, at least.

It does implement AsyncRead and Write, because anything with `Read` and `Write` implements it: https://docs.rs/async-std/0.99.3/async_std/io/trait.Read.htm... (that's sadly a little backwards by rustdoc)

The problem is that tokio has their _own_ versions of the AsyncRead and Write traits.

Hyper can best be used with `async_std` through `surf`: https://github.com/rustasync/surf

Re: Async-std: an async port of the Rust standard library

#113

Post by Argorak »

jeremyjh wrote: post #90
Argorak wrote: post #76

Earlier quoted context omitted.

I wouldn't rely on that. Next step, someone binds to a blocking database driver and you are back at square 1 again. This is definitely not rigorous. I would love to see a lint for known-blocking constructs in async contexts, though: https://github.com/rust-lang/rust-clippy/issues/4377 Also, having explicit imports and types that name collide helps there for once.

How would you have a blocking database library that doesn't use the standard library?

Any code in Rust is free to bind to FFI and sockets can be gained through `libc`.

Re: Async-std: an async port of the Rust standard library

#115

Post by Arnavion »

Argorak wrote: post #112
Arnavion wrote: post #105

Earlier quoted context omitted.

If all you needed from tokio was tokio::net, then async-std could work as a replacement for raw TCP stuff. If you needed the higher-level stuff from tokio like codecs then you'd not have those. Also, anything from the tokio ecosystem like hyper would not work with async-std. Edit: I originally had a first paragraph which was wrong. I mistakenly thought std::net::TcpListener is supposed to impl Read / Write.

> async-std has the equivalent of std::net::TcpListener, however it does not appear to actually impl AsyncRead / AsyncWrite. So as of now you can't do anything with it. TcpStream does impl them, at least. It does implement AsyncRead and Write, because anything with `Read` and `Write` implements it: https://docs.rs/async-std/0.99.3/async_std/io/trait.Read.htm... (that's sadly a little backwards by rustdoc) The problem…

>It does implement AsyncRead and Write, because anything with `Read` and `Write` implements it: https://docs.rs/async-std/0.99.3/async_std/io/trait.Read.htm... (that's sadly a little backwards by rustdoc)

>impl Read for T {

That's saying that anything that impls futures::AsyncRead impls async_std::io::Read. async_std::net::TcpListener does not impl AsyncRead. (Compare with TcpStream and File which do.)

>Hyper can best be used with `async_std` through `surf`: https://github.com/rustasync/surf

Sure. You also don't need surf since you can directly use futures's compat executor wrapper around tokio's. The point is that you can't use stuff like hyper without the tokio executor being involved.

Re: Async-std: an async port of the Rust standard library

#116

Post by khuey »

jeremyjh wrote: post #90
Argorak wrote: post #76

Earlier quoted context omitted.

I wouldn't rely on that. Next step, someone binds to a blocking database driver and you are back at square 1 again. This is definitely not rigorous. I would love to see a lint for known-blocking constructs in async contexts, though: https://github.com/rust-lang/rust-clippy/issues/4377 Also, having explicit imports and types that name collide helps there for once.

How would you have a blocking database library that doesn't use the standard library?

unsafe

Re: Async-std: an async port of the Rust standard library

#117

Post by Arnavion »

Arnavion wrote: post #115
Argorak wrote: post #112

Earlier quoted context omitted.

> async-std has the equivalent of std::net::TcpListener, however it does not appear to actually impl AsyncRead / AsyncWrite. So as of now you can't do anything with it. TcpStream does impl them, at least. It does implement AsyncRead and Write, because anything with `Read` and `Write` implements it: https://docs.rs/async-std/0.99.3/async_std/io/trait.Read.htm... (that's sadly a little backwards by rustdoc) The problem…

>It does implement AsyncRead and Write, because anything with `Read` and `Write` implements it: https://docs.rs/async-std/0.99.3/async_std/io/trait.Read.htm... (that's sadly a little backwards by rustdoc) >impl Read for T { That's saying that anything that impls futures::AsyncRead impls async_std::io::Read. async_std::net::TcpListener does not impl AsyncRead. (Compare with TcpStream and File which do.) >Hyper can bes…

Actually, I'm just being dumb. TcpListener isn't supposed to impl AsyncRead / AsyncWrite in the first place. std::net's one doesn't impl Read / Write either.

Re: Async-std: an async port of the Rust standard library

#118

Post by staticassertion »

nullwasamistake wrote: post #102
pcwalton wrote: post #80

Earlier quoted context omitted.

> I thought Rust had other, better ways to create non-blocking code so I don't understand why to use async instead. In fact, Rust does have a great solution for nonblocking code: just use threads! Threads work great, they are very fast on Linux, and solutions such as goroutines are just implementations of threads in userland anyway. (The "what color is your function?" post fails to acknowledge that goroutines are jus…

Threads are bad for high concurrency. Specifically when you need to call out to another service that has some latency. Say you have 1000 threads. To handle a request each one needs to make 50ms of external or DB calls. In one second, each thread can handle 20 calls. So you can handle 20k requests/second with 1000 threads. But Rust is so fast it can serve 500k requests a second. So with regular threads, you need ~25,0…

Java services have managed for a long time to do just fine. Usually you just have dedicated threadpools for those db/ whatever calls.

But yes, eventually, for very heavy cases (more than what I would call "high") you will want async/await.

Re: Async-std: an async port of the Rust standard library

#119

Post by jeremyjh »

Argorak wrote: post #113
jeremyjh wrote: post #90

Earlier quoted context omitted.

How would you have a blocking database library that doesn't use the standard library?

Any code in Rust is free to bind to FFI and sockets can be gained through `libc`.

I didn't literally mean "How is that possible?"

I meant: is that a real thing? Is there a database binding out on crates.io that uses no_std ?

Re: Async-std: an async port of the Rust standard library

#120

Post by steveklabnik »

jcrites wrote: post #110
wahern wrote: post #69

Earlier quoted context omitted.

The article explicitly admits that async/await is ergonomically much nicer than explicit futures/promises. But the color problem still remains, one consequence of which is duplication of code and interfaces. Arguing that the problem doesn't exist if you only stick to functions of a single color isn't a rebuttal, it's an admission! But the fact of the matter is async functions have real limitations and costs, which is…

I think the point is that "colored" functions only existed because Rust did not previously have async support. Now that it has async support, new code can be one color: async, while maintaining ergonomics. Maybe new code will be exclusively async and existing code will switch over.

We can never eliminate sync stuff, because async requires a runtime. Async is great when you need it, but you don't always need it, and you shouldn't have to pay the cost if you don't plan on using it.
Post reply on HN