Some musings on the async ecosystem and compatibility between async-std and tokio... 1/15
-
-
Instead of creating a TcpStream inside your async library, let the user create one for you and then accept any stream implementing AsyncRead and AsyncWrite as an argument. 7/15
Show this thread -
To illustrate what that means in practice, let's compare hyper and async-h1. 8/15 https://docs.rs/hyper https://docs.rs/async-h1
Show this thread -
Here's a hyper server running on async-std. 9/15 https://github.com/async-rs/async-std-hyper/blob/6025fafe549a2b4715c8bf9e80fa8240be81ff8a/src/main.rs …pic.twitter.com/sMHgFGGMy4
Show this thread -
Here's an async-h1 server running on async-std. 10/15 https://github.com/http-rs/async-h1/blob/f930e7bbbb48c21c69535ab86a4cdc5a36ecde49/examples/server.rs …pic.twitter.com/nxKAja8Cdz
Show this thread -
Hyper requires a lot of glue code because it starts an HTTP server on its own and then needs to invoke your runtime's functions. 11/15
Show this thread -
In contrast to that, async-h1 lets you create a TCP listener and accept TCP streams on your own. Then, all async-h1 does is it reads HTTP requests from an AsyncRead and writes HTTP responses into an AsyncWrite. 12/15
Show this thread -
The key difference is: hyper acts like a framework because it invokes your code, while async-h1 acts like a library because it's invoked by your code. 13/15
Show this thread -
Async-h1 doesn't even care about the actual HTTP server - it's basically an async HTTP serialization/deserialization library! 14/15
Show this thread -
In conclusion, prefer async libraries over async frameworks. If async libraries only use the standard Future/Stream/AsyncRead/AsyncWrite traits to interface with the outside world, we won't end up with an ecosystem split. 15/15
Show this thread
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.