Good morning rustlers! Today I’ve got an intentionally broad question to ask. If you’re someone who would like to use Rust “on the server”, be it as a hobby or in your production environment, what is blocking you from using Rust on the server today?
One of the roadmap goals for Rust in 2017 is that “Rust should be well-equipped for writing robust, high-scale servers.” We’ve already made some great progress on this item throughout 2017 but now that we’re reaching the midway point through 2017 I’d like to take stock of just quite how far we’ve come and where our next highest value targets are. Some examples of work towards this goal so far are:
- Continuing development on asynchronous support in Rust with the
futurest crate and Tokio stack.
- Having a high performance HTTP library like Hyper
- Continued development web frameworks like Rocket
- New production users of these technologies like linkerd-tcp
Even given all this though, I’m confident that we can continue to go much farther and really drive home this roadmap goal by the end of the year! I’m hoping to have a good open-ended discussion about what you think is missing from Rust’s story-on-the-server. Are futures too confusing? Is async/await syntax a blocker? Is our synchronous I/O story lacking critical features? Are there still key libraries missing? Do existing libraries need an API review? All kinds of questions and answers are more than welcome!
So, what is blocking you from using Rust on the server today?
I figured it’d also be good to start out by sharing my own thoughts! I personally feel that’s Rust’s story on the server is going to be very firmly rooted in the “async world”. This may not be for the precise reason you’d imagine though! It’s generally accepted that best-in-class performance when you’re doing lots of I/O necessitates the usage of asynchronous I/O, which I think is critical to Rust’s use case in servers.
Not all servers, however, will need the highest level of performance! For the same reason that many servers today are dominated by “slower” languages like Ruby and Python, I don’t think we need to 100% focus all effort for Rust-on-the-server into speed. Despite this, however, I still believe that the “async world” is the highest value target. How often have you needed to time out an operation? Maybe opportunistically try two requests at the same time and cancel the second when the first completes? Maybe you’re waiting for both a remote RPC and your worker thread to produce a result to continue. Or perhaps you just need to set up two independent data processing pipelines that get woven together at the end? I’ve found these sorts of desires to be quite common when working with servers, but they’re all quite hard to get right with synchronous I/O while trivial to get working with async!
I believe working with asynchronous I/O and futures empowers you with so much more than you’d otherwise get with typical blocking and synchronous I/O. These extra superpowers, which many non-performance-critical servers end up needing, are what we can capitalize on in Rust. Another huge benefit to staying rooted in asynchronous I/O as well is that your server can scale as you need it, if you discover a performance bottleneck you’re already equipped with one of the fastest I/O frameworks in the world, it won’t take a whole rewrite to use it!
So that’s at least my personal rationale for pushing real hard on async vs the sync story in Rust today (which I also think is “pretty good” as-is). We’ve got a long road ahead of us though with async, particularly:
Getting up to speed on Tokio/Futures is empirically difficult, way too many people are bouncing off at this point. We need to refocus on our existing documentation and basically restructure it from the ground up to be more amenable to newcomers. There’s a lot of opportunity here and we’ve got a lot of ideas on how to do this too!
Async/await notation is going to be critical for widespread adoption of futures. Writing synchronous code is easy, and async/await is just writing asynchronous code but without knowing it! In terms of easing the learning curve this seems like one of our highest value propositions.
I have the feeling that there’s not as much production use of Tokio/futures as I would like. Production users are critical for motivating development of foundational libraries, providing real-world feedback about things like debugging and performance, and helping to flesh out bugs and stress everything to its limits. This thread here I hope can help get new production users in the pipeline!
Finally, I feel that we’re not quite where we want to be yet with the HTTP story. I think we’re still missing a prominent HTTP/2 library which means that common protocols like GRPC are difficult to use in Rust. Similarly on the HTTP/1 side of things I at least feel that we’ve come a long way but still have further to go before we can satisfy our roadmap goal.
If we can get all of those really nailed down by the end of the year then I think we’ll be in fantastic shape for Rust-on-the-server. The work by no means stops here, and I’m sure that you’ve also got your own blockers and opinions! I’m quite eager to hear what you’re thinking!