Rust 2019

3 minute read Published: 2019-01-01

Lets start with me & Rust in 2018

So 2018 was really my big introduction to Rust year. I had experimented with it previously, but this was the first year I got to use it professionally (both for a client project and for a new internal tool), and thus the first time I got to make a proper Rust project.

However it still has some way to go for me to feel comfortable with it as my #1 go-to language on a day to day, and also to persuade my colleagues to choose it.

What I want from Rust in 2019

Three major things

The first point is one that is in progress, I am just waiting for, and hope will happen soon, so will not focus too much on it here.

Web frameworks and Rust

The second point is a tricky one. So my background is in building web applications/servers for apps to talk to. I have done this across several languages (Ruby/Node/PHP being main ones). Each language has seemed to morph into it's own way of handling a framework - Ruby has Rails, Node seems to lean more towards minimal core frameworks like Express and Hapi, and php has of course Laravel and Symphony.

My experience with Rust frameworks is that currently we haven't yet settled into our way of handling a framework. Most of the frameworks I have dealt with (Nickel and Gotham) seem to be trying to replicate Express in Rust, which while express is a good model for a minimal framework it just feels like you are almost fighting the nature of rust to make it work?

The current attempts to do something a bit different with rust and the web (Rocket & Actix-web) still just do not yet feel right to me (this may be due to lack of time to properly get to grips with them, but so far neither has felt right when I tried them).

I am not sure where this unease/conflict between Rust and the web (for me at least) comes from, part of it may be thinking about (whether in my head or in the design of the framework) the web application in a too object-oriented manner, instead of a more data-first manner.

Testing and Rust

First and foremost with this point, this is not meant as a criticism of the existing Rust testing, that is brilliant and works for most cases. I am however finding with certain recent projects I feel that there may need to be more dedicated tools developed for testing (I realise that some of the use cases may be satisfied by individual crates, but I want a more comprehensive solution). In essence, I want an RSpec (Ruby testing library) but for rust. I want some of that testing magic that makes writing tests in Ruby so relatively easy compared to all the boilerplate needed for tests in Rust currently.

In my head this has several main things which it needs to provide - a way to easily make mocks/stubs/doubles (probably would mean restructuring app type signatures to expect trait-based signatures instead of actual types), a way to do full before/after hooks (example from rspec docs of hook order):

before :suite
before :context
before :example
after  :example
after  :context
after  :suite

And a way to structure tests in a more human/less code manner.


Rust is an amazing project, but I feel it needs some polish, a lot of other good blog posts by many other people have gone into those details, so I chose to focus on what I needed for work. At the moment I do not have a lot os solutions to the problems I have mentioned, and also do not have much time to work on developing solutions, but I can hope that this post may help spark an idea with someone (or I find the time and remember this post and can work on an idea).