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?
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.
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
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.
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
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.
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
#[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
-- as well as
--nocapture? And, why does
cargo help test
--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.