programming archaeology, pedantics, and machine intelligence

21 Jan 2012

Some notes on Rust

Following the release of version 0.1, I had another look at Mozilla’s new systems programming language.


If Go is C revisited by C hackers, Rust is C revisited by ML hackers.

The language has come a long way since the initial announcement over a year ago. There’s a new website, documentation, a standard library, and the compiler has been ported from OCaml to Rust itself.

Rust tries to combine C-like support for low-level programming (control over memory layout and management) with features found in modern functional programming languages (pattern matching, type inference, and higher-order functions are all present, albeit in a more restricted form than you’d find in OCaml or Erlang), message-passing concurrency, and lots of static safety checking thanks to its type, kind and typestate systems. There’s also a preprocessor, with a macro system currently in development. Immutability is the default. The syntax is a mix of C++ and OCaml.

Rust exposes more implementation details than most current programming languages (e.g. the programmer explicitly creates either stack- or heap-allocated closures) which will hopefully pay off when it comes to tuning performance-critical systems code.

Concurrency is based on tasks which do not share data and communicate via message passing. Messages are sent through typed channels. Spawning tasks creates an implicit supervision tree where failures are propagated to the parent.

Rust’s typestate system is particularly interesting to me. Intuitively, in addition to having a type, objects are in different typestates of that type at different points in the program (e.g. initialized or uninitialized). Operations cause typestate-transitions, defined by a typestate-precondition and a set of typestate-postconditions. The operations in a program therefore induce a graph on typestates which the typestate-algorithm tracks at compile-time.

For basic blocks, the algorithms simply applies the transitions associated with each operation on the in-typestate to get the out-typestates. The in-typestate of a basic block is the greatest lower bound of the out-typestates of all basic blocks preceding that basic block in the control-flow graph. In practice, this means that certain assertions can be checked statically.

In particular, the check keyword guarantees that its argument, a pure predicate applied to immutable values, would have returned true if that point of the program is actually reached.

I was a bit disappointed by the lack of support for alternative operating systems (BSD Unices, illumos/SmartOS), but aside from that, congratulations to the Rust team for shipping their first major release and I hope to have written an actual Rust program before 0.2 is out.