Today we're going to take a brief look at two crates from the same author - Andy Barron. The first of them is app_dirs - a useful library to find platform-dependent directories, such as application configuration, data directory or cache. The second crate for today is preferences, which provides a simple way of managing user preferences and other data relevant to our program.

Fact: I'm writing these articles and examples on a Windows machine and so far everything compiles and works as expected. Just so you know, Rust supports Windows in the top tier. I'm mentioning it here since a few people I talked to assumed Windows support was sort of secondary, bolted-on later. This is not the case.

The library ecosystem also supports different operating systems fairly well. There are even cross-platform crates for stuff usually associated with Linux, such as curses or coreutils. However, some crates support only Linux or Windows by design. One of them is winreg - a Rust API to access Windows Registry.

Two years ago I wrote an article about working with JSON in Rust. JSON (de)serialization support was then baked in the standard library. However, at that time Rust was at version 0.13 and a lot of things happened since then. Mainly, the rustc-serialize crate got pulled out of the core libraries, but kept its close relation to the rustc compiler itself. (Hence the slightly awkward name.)

Meanwhile, a new contender arose: serde. It is also a generic serialization framework for Rust. It's more modern, actively maintained and gets lots of love from the community. There's a selection of supported data formats, including JSON, YAML, MessagePack as well as several others. Even the official docs for rustc-serialize say (emphasis mine):

While this library is the standard way of working with JSON in Rust, there is a next-generation library called Serde that's in the works (it's faster, overcomes some design limitations of rustc-serialize and has more features). You might consider using it when starting a new project or evaluating Rust JSON performance.

Important note: this article is outdated! Go to http://zsiciarz.github.io/24daysofrust/ for a recent version of all of 24 days of Rust articles. The blogpost here is kept as it is for historical reasons.

One of the few chores when building a commandline program is argument parsing, so that myprogram --config=myfile.conf --verbose -o output.txt makes sense. Some arguments come in short and long variants, some are optional and some are positional only. There are a lot of libraries for argument parsing, some are even included in the respective languages' distributions. In Rust's case there's the getopts crate.

The first thing a moderately savvy user will do is... no, not read the documentation, but run myprogram -h (or --help) to discover available options. getopts and other libraries can derive such help summary for you, saving your time and reducing duplication. But what if it was the other way round? You'd write the usage message, listing possible options, and the tool would build an argument parser from that. Enter docopt.