nrc

Rust developer tools - status and strategy

Availability and quality of developer tools are an important factor in the success of a programming language. C/C++ has remained dominant in the systems space in part because of the huge number of tools tailored to these lanaguages. Succesful modern languages have had excellent tool support (Java in particular, Scala, Javascript, etc.). Finally, LLVM has been successful in part because it is much easier to extend than GCC. So far, Rust has done pretty well with developer tools, we have a compiler which produces good quality code in reasonable time, good support for debug symbols which lets us leverage C++/lanaguge agnostic tools such as debuggers, profilers, etc., there are also syntax highlighting, cross-reference, code completion, and documentation tools.

In this document I want to layout what Rust tools exist and where to find them, highlight opportunities for tool developement in the short and long term, and start a discussion about where to focus our time an

nrc

When converting from a smart pointer type to a borrowed reference, you need to 'cross-borrow' data. This requires writing &*expr or &**expr, etc. This is usually just annoying - it doesn't help to read or write the code. When writing, you play 'type Tetris', inserting *s until the compiler is happy. When reading it is just line noise. At best, if you are passing a value to a function, it tells you that you are passing a borrowed reference, not owned data. Alternatively, that you are passing by reference, not value.

So, we would like to spare the programmer this burden. The question is how. There have been a few proposals (rust-lang/rfcs#226, rust-lang/rfcs#241, rust-lang/rfcs#248). A central question when evaluating these proposals is whether the programmer should care first about the borrowed-ness of data or about the amount of indirection to the user. I am starting to lean more towards the position of making ownership/borrowing s