A Fresh Look at Rust

Where is Rust Positioned?

The three languages where I do most of my work in are Python, C and C++. To C++ I have a very ambivalent relationship because I never quite know which part of the language I should use. C is straightforward because the language is tiny. C++ on the other hand has all of those features where you need to pick yourself a subset that you can use and it's almost guaranteed that someone else picks a different one. The worst part there is that you can get into really holy wars about what you should be doing. I have a huge hatred towards both the STL and boost and that has existed even before I worked in the games industry. However every time the topic comes up there is at least someone who tells me I'm wrong and don't understand the language.

Rust for me fits where I use Python, C and C++ but it fills that spot in very different categories. Python I use as language for writing small tools as well as large scale server software. Python there works well for me primarily because the ecosystem is large and when it breaks it's a super straightforward thing to debug. It also keeps running and can report if things go wrong.

However one interesting thing about Python is that unlike many other dynamic languages, Python feels very predictable. For me this is largely because I am a lot less dependent on the garbage collector than in many other languages. The reason for this is that Python for me means CPython and CPython means refcounting. I'm the guy who will go through your Python codebase and break up cycles by introducing weak references. Who will put a refcount check before and after requests to make sure we're not building up cycles. Why? Because I like when you can reason about what the system is doing. I'm not crazy and will disable the cycle collector but I want it to be predictable.

Sure, Python is slow, Python has really bad concurrency support, the interpreter is quite weak and it really feels like it should work differently, but it does not cause me big problems. I can start it and it will still be there and running when I come back a month afterwards.

Rust is in your face with memory and data. It's very much like C and C++. However unlike C and C++ it feels more like you're programming with Python from the API point of view because of the type inference and because the API of the standard library was clearly written with programmer satisfaction in mind.

You will run into Walls

I think an interesting thing about programming in Rust is that in the beginning you will run into walls. It's clearly not Python so lots of things you can get away with in Python do not work in Rust. At the same time it's not C++ and the borrow checker will become your greatest enemy. You will write some code and say: this stuff really should work, why do you think you know better and stop me from doing this you stupid thing?

The truth is that the borrow checker is not perfect. The borrow checker prevents you from doing dangerous things and it does that. However it often feels too restrictive. In my experience though the borrow checker actually is wrong much less often than you think it is and just requires you to think a bit differently.

I like the borrow checker personally a lot. I agree with that sometimes you feel there should be a way to disable it, but when you think more about it you are quite happy it's there. The borrow checker prevents you from building up some of the worst technical debt you can acquire, the kind of debt which you can never repay. The Python programming language acquired a global interpreter lock when it got threading support and it really required it ever since the language existed. The interpreter was written in a way that nowadays we are not sure how to make it concurrent.

If you try, you can still make terrible decisions for concurrency in Rust, but you really need to go out of your way to do it. The language forces you to think more and I believe that's a good thing. I don't want to become another "objective oriented programming is the billion dollar mistake" preacher but I do think that the language decides largely what code people write. Because subclassing is easy in C++, Java, Python and many more languages this is what we write. And then birds are instances of animal classes. If you take that tool away you start thinking differently and that's a good thing. CPUs stop getting faster and looking at one object at the time really no longer makes any sense at all. We need to start reasoning a lot more about collections of things and what transformations we actually want to do.

Rust Inspires

For me programming in Rust is pure joy. Yes I still don't agree with everything the language currently forces me to do but I can't say I have enjoyed programming that much in a long time. It gives me new ideas how to solve problems and I can't wait for the language to get stable.

Rust is inspiring for many reasons. The biggest reason I like it is because it's practical. I tried Haskell, I tried Erlang and neither of those languages spoke "I am a practical language" to me. I know there are many programmers that adore them, but they are not for me. Even if I could love those languages, other programmers would never do and that takes a lot of enjoyment away.

Rust is something that anyone can pick up and it's fun all around. First of all (unless you hit a compiler bug) it won't crash on you. It also gives you nice error messages if it fails compiling. Not perfect, but pretty good. It comes with a package manager that handles dependencies for you, so you can start using libraries other people wrote without having to deal with a crappy or non existing ecosystem. Python got much better over the years but packaging is still the biggest frustration people have. Cargo (rust's package manager) is barely half a year old, but it has a full time developer on it and it's fun to use.

Even just the installation experience of the language is top notch. It gives you compiler + documentation tool + package manager and you're good to go. The fact alone that it has a documentation tool that spits out beautifully looking documentation out of the box is a major contributor to enjoying programming in it. While I wish it had a bit more of Sphinx and a bit less of javadoc, it's a really good start for more.

But what's really inspiring about Rust are the small things. When I first played with Rust what amazed me the most was the good FFI support. Not only could you call into C libraries easily: it also found and linked them for you. There is so much more though and it's hidden everywhere. There is a macro (include_str!) that will read a file next to your source at compile time into a string into your binary (How cool is that!?). Not only can you bake in contents of files, you can also pull environment variables into your binaries for instance.

Designing APIs

The most interesting part currently is definitely finding out how to properly write APIs for Rust. Rust as a language is undoubtedly more complex than most other but thankfully not in a way that it overwhelms you. What makes Rust complex from an API point of view is that as a programmer you feel a bit of a tension between writing the straightforward code that you expect when programming in a systems language and providing a nice high level API like you expect in Python.

The reason I feel making nice APIs is because the language encourages it. First of all the language in itself is super expressive and it makes a lot of fun to write things in it — on the other hand there is just so much possibility.

To give you an idea why it's fun to design APIs for Rust is that the type system is just so damn good. So Rust is statically type checked but it has inference so you get away with writing really beautiful code. In my rust driver for instance, you can write code like this:

extern crate redis;

fn main() {
    let client = redis::Client::open("redis://127.0.0.1/").unwrap();
    let con = client.get_connection().unwrap();

    let (k1, k2) : (i32, i32) = redis::pipe()
        .cmd("SET").arg("key_1").arg(42i).ignore()
        .cmd("SET").arg("key_2").arg(43i).ignore()
        .cmd("GET").arg("key_1")
        .cmd("GET").arg("key_2").query(&con).unwrap();

    println!("result = {}", k1 + k2);
}

To give you an idea how the same code looks in Python currently:

import redis

def main():
    client = redis.Redis('127.0.0.1', 6379)
    pipe = client.pipeline()
    rv = pipe \
        .set("key_1", 42) \
        .set("key_2", 43) \
        .get("key_1") \
        .get("key_2").execute()
    k1 = int(rv[2])
    k2 = int(rv[3])
    print 'result = {}'.format(k1 + k2)

if __name__ == '__main__':
    main()

What I find interesting about this is that the Rust library is nearly as small and clear as the Python one, but is a much lower-level binding. Unlike the Python library which gives each call a separate method, the Rust library (because quite new) only wraps the low-level API and you need to create the request manually by chaining calls for each argument. Yet the end result for a user is nearly as nice. Granted there is extra handling needed in Rust for the errors (which I avoided here a bit by using unwrap which makes the app terminate, but then the same is the case in the Python version where I also miss error handling).

The cool thing though is that the Rust library is completely type safe. And yet in total there are exactly two places where types are mentioned and that's the same ones, where a cast to an integer was necessary in Python.

This however is not the best we could do in Rust. Rust has compiler extensions which open up a whole range of possibilities. For instance there is a Rust library which statically verifies that Postgres SQL commands are well formed: rust-postgres-macros:

test.rs:8:26: 8:63 error: Invalid syntax at position 10: syntax error at or near "FORM"
test.rs:8     let bad_query = sql!("SELECT * FORM users WEHRE name = $1");
                                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

This sort of stuff excites me a whole lot.

(If you're into API design in rust, join us in #rust-apidesign on the Mozilla IRC network)

Rust's Future

Is Rust's memory tracking concept strong enough that we will accept it as a valid programming model? I am not sure. I do believe though that Rust can stand on its own feet already. Even if it would turn out that the borrow checker is not sound, I believe it would not hurt the language at all to widespread adoption. It's shaping up to be a really good language, it works really well without GC and you can use it without a runtime.

Rust is an exceptionally good open source project. And it needs more helping hands. The Windows support (while getting better) especially needs more love.

If there is interest in some more practical Rust experience I will probably write something up about my experience making redis-rs.