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
1 reply 0 retweets 4 likesShow 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
1 reply 0 retweets 4 likesShow 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
1 reply 0 retweets 2 likesShow 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
1 reply 0 retweets 3 likesShow 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
1 reply 0 retweets 9 likesShow this thread -
Async-h1 doesn't even care about the actual HTTP server - it's basically an async HTTP serialization/deserialization library! 14/15
1 reply 0 retweets 6 likesShow 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
4 replies 3 retweets 27 likesShow this thread -
Replying to @stjepang
Sorry for bothering, newbie rust learner here, would something like this helps? Just found out this crate the other day. https://github.com/najamelan/async_executors … Which seems aiming to solve part of the problem.
1 reply 0 retweets 0 likes -
Replying to @extraymond
I think that approach encourages hyper's philosophy, but gets around the problem by abstracting over all currently available runtimes. In a way, "async_executors" is a spiritual successor to "runtime".
1 reply 0 retweets 1 like
However... right now we have only 2 major runtimes so it's a very reasonable solution to abstract over their interfaces. But I worry what happens when we have 10 or 100 runtimes? Does this approach scale?
-
-
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
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.