Fighting Instability and Rust

Published on: January 15, 2018

Banner generated through trianglify

Update: February 5th, 2018: all of the issues written about in this post have been resolved. The beauty of open source is the community and the transparency.

I wrote an article about a month ago titled Replacing Elasticsearch with Rust and SQLite that can be seen in the rrinlog project. It’s a simple web app that talks to a database. The two main libraries:

• Rocket as the web framework
• Rocket is pre-1.0 and can only be built on nightly Rust
• diesel for interacting with the database
• diesel recently turned 1.0 and can be built on stable, beta, and nightly Rust

Thanks to diesel 1.0, I was able to replace manually deriving QueryableByName with the derive macro in this commit. Then things started to go wrong.

The Rocket version I locked down to broke on the latest nightly. These things happen, nightly Rust doesn’t make guarantees about stability. The fix is typically upgrading to the latest Rocket, usually not a big issue, except this time, the latest Rocket broke on nightly because of the nightly version broke the dependency ring. To me, the drama was surreal. A combination of cross linking, alpha versions, module paths, herd mentality led to a temporary impasse. I highly recommend diving into the linked issue, as it is the most tense I’ve ever seen the Rust community. The only solution was to pin the nightly version of Rust with a specific version of Rocket. Thankfully in the last couple days, the community has worked past the problem due to some very hard working members. I think this has been a testament to Rust’s budding open source ecosystem to find the correct balance of convenience, backwards compatibility, and security.

Ok, nightly is fixed, but a failing Rust beta build slipped under the radar. Diesel failed to install, but the compiler is at fault. As of writing, the issue hasn’t been fixed, but I bet will be fixed soon, as I hold the Rust compiler writers in high esteem. The silver lining here is that this beta issue was caught before the problem slipped in stable Rust – that would have been extremely jarring. This is why projects should test projects on beta!

All these issues have been a tad frustrating as the majority of my Travis CI builds have failed. To some extent I think it reflects badly on Rust. All these failures for a simple web app have made Rust look less stable than reality. My original article was advocating Rust in situations where pre-existing solutions aren’t ideal – and I can’t in good faith recommend this ecosystem that’s been “broken” for the past month. This all will be water under the bridge, and Rust will emerge stronger than ever, but until then I’ll grit my teeth and focus on other use cases for Rust.