I’ve been thinking of writing a post about my experiences with Rust for a while, but haven’t found the time. The call for Rust#2019 posts seems like an good opportune moment to contribute.

My rust experience is extremely limited. I’ve written a single library in Rust, called Horned-OWL, (n.d.a) for manipulating OWL (n.d.b/) I started it in August 2017 and it took over a year to full implement the spec complete with parser and renderer; a length of time that is more reflective of the sporadic availability of time that I have to work on these things rather than anything else.

And the experience has been positive. There is already a good and complete library for manipulating OWL called the OWL API (n.d.c) so I needed a strong motivation for writing another. That motivation is simple: the OWL API is in Java and it is slow. Rust has fulfilled it’s promise for me; Horned-OWL is an order of magnitude faster thatn the OWL API.

What have I learned from the experience though, and what could be improved?

Community

I thought I would start with my experience of the community first. Rust is famous or infamous around the internet. In a modern day version of Godwin’s Law, any discussion of Rust results in accusations of SJWs in a remarkably short space of time. I should show my cards here; I’m all in favour of social justice, so I was not put-off my this but curious.

And, actually, I have found the community remarkably helpful; I have recieved in-depth and clear replies to any questions that I have posted on the Rust forums. I’ve also learned something from the community. I have seen it answer questions that I considered foolish or of the “please do my home work for me” kind, while maintaining a high-level of politeness. In the end, I think this is good; perhaps a more blunt response to foolish questions would educate the questioner but always erring on the side of politeness makes the Rust forums a happy place to be. I wish it were true of the wider internet.

My only criticism would be that many of the community are really bought into the process of Rust; as a result many will offer solutions that say “in the future you will be able to do this…​” or “if you use nightly, then…​”. This can be a little confusing when I am trying to build software now, based around some form of stability.

Documentation

Over all the standard of documentation for Rust is high. I read the rust book and found it to be useful and informative.

I would raise one area for improvement. Rust is attempting to achieve something novel and many in the community are very bought into this; as a result, I think, discussions of where Rust’s model causes problems are minimized. I spent several fruitless days, for example, trying to lazily instantiate a data structure. The solution is short and simple and unsafe. Similarly, I struggled for a long time with building a circular data structure; in this case, I tried several (first Rc, then numeric indexes for nodes, finally tree structure with Rc identifiers to make circular).

Documentation-wize, Rust needs to embrace it’s capabilities for writing unsafe and circular data structures. It can do this perfectly well, and new developers need to know how early.

Learnability

The theme of Rust 2018 was productivity. And it has achieved good things here. But for me, the biggest problem that Rust has remains all the users that it does not have. One significant reason for this must surely be it difficult learning curve.

Productivity is a form of usability, but it is not the same thing as learnability. Some of the changes in Rust 2018 do improve learnability: while learning the old module system, for example, I found myself lost and often ended up using one of the strongest techniques in any programmers toolkit; I changed things randomly until it worked. Other changes, such as the ? or impl trait improve productivity, but also introduce new syntax which hampers learnability.

Let me give an example. I am old school enough as a programmer that I use “print everything” is one of the ways I program (and something I teach!). If you use this technique in Rust, you hit three learnability problems. First, these two statements seem backward.

println!("{?}", object);
println!("{:?}", object);

The one I want to use most frequently is the second form (i.e. print anything out). Yet, it’s longer than the first. At the same time, when I try to use the second form, it frequently doesn’t work. Not until, I have added #[derive(Debug)] everywhere. Why? Is there really no way to allow Rust to produce some printable representation for any object, even if it’s just the name of the type and an identifier.

And, finally, to have this work with your test suite you have to do this:

cargo test -- --nocapture

Why the -- as well as --nocapture? And, why does cargo help test not describe --nocapture as an option.

So, for 2019, I would focus on learnability, to consolidate the gains made by Rust 2018. What would this mean in practice? I don’t know all specific steps it should mean, because I am not totally new to Rust any longer (I am now using a strange combination of the old and new module imports). I would suggest that each Rust developer mentor one or two Rust incomers and use this time to understand what the issues are; perhaps, this reflects my academic background, but I am a great believer in the principle that you don’t understand something till you have taught it.