The Road to Rust Web 1.0

Amidst all of the talk surrounding the Road to Rust 1.0, I thought it would be fitting to talk about the corner of Rust with which I am most familiar, and what it will take to get Rust web dev to “1.0.”

First things first, let’s celebrate what we’ve accomplished!

Rust web-dev has come a very long way in the past months, with the development of frameworks and libraries like Iron, Nickel and Conduit and new fundamental HTTP implementations like Teepee and Hyper, developing Rust web applications has become much easier.

Many Rust web projects are still under active development, with new features and improvements landing every day. For instance, Iron has landed a huge refactor, Nickel has landed middleware, and Hyper has landed a working beta.

Even with all this progress, we still have a ways to go. Most of these projects are still in beta and all are pre-1.0 and any promise of stability. To get to the point where application developers will be ready to use Rust to design applications, these are the biggest things that have to stabilize:

1. Application Frameworks
2. HTTP + HTTPS Server Implementations
3. HTTP + HTTPS Client Implementations
4. Database bindings

That’s it. You will notice that this list has much in common with what we have now — but stabilized. I feel that many of the other things that some consider necessities can be free to grow on top of these fundamental layers without further support from them — things like an ORM, email, etc.

Getting to that stage is still hard. These are the biggest blockers that I perceive to getting to the desired level of stability:

1. Server-Side SSL and HTTPS
2. A non-blocking IO abstraction for building C10k servers
3. Confidence

Server-Side SSL is relatively self-explanatory; we want HTTPS because we need secure connections. This is really a basic requirement for building non-trivial applications and it’s a serious wart that we don’t have it already.

Rust, not just web Rust, needs non-blocking IO to reach the pinnacle of its performance potential and for us to build massively concurrent systems — spawning 10k threads for 10k connections will not work out in the long run.

The blocking, threaded model that Rust exposes today is a pleasure to program in and is much better than something like node’s CPS, but it is also limiting. Spawning and scheduling threads is and will always be expensive, whereas low-level bindings over kqueue and epoll are cheap and will remain so. It’s a tradeoff, but this is a choice that users of Rust have to be able to make.

There is a lot of good discussion of this issue in the RFCs (one and two) for the removal of libgreen and the runtime, so I won’t drone on further on this here.

Lastly we need confidence — confidence in our APIs, our decisions, our tools, and our libraries. At one point we will need to decide, like Rust, what our “1.0” looks like and we will need confidence in that decision if we want to drive Rust web development forward.

I will be spending some time this week to consider what stability means for the projects I lead (you can expect more posts to come). I encourage everyone else with a name in the game to do the same.

Discuss on Reddit

Discuss on HN