Lecture: Everything Revisited

Dear students:

Today we switch to our final language of the semester: Rust. We will see some new ideas that Rust contributes to programming language landscape, but its primary strength is that it blends together a lot of great ideas that we've already seen without the ascetism of Haskell.

We'll have a look at this upstart of a language. When I was first learning to code, I loved writing lots of little main programs that did silly things. I'm still learning to code, and my love of silly mains persists. So that's how we'll begin. We won't enumerate all the features of the language.

Countdown

Imagine you want a little timer to help you take a break from staring at a screen. Certainly we could call up one of the many apps on your phone or the web, but they pose more opportunities for distraction. We want one that runs in the terminal. Let's write it in Rust. Our main function starts off with a variable marking the current time:

Rust

fn main() {
  let time = 60;
}

fn main() {
  let time = 60;
}

Notice there's no explicit type. What kind of typing system do you suppose Rust has? Dynamic or static?

What do I need next? Display the time. Tick time downward. Sleep. Repeat. Let's tick first with an arithmetic assignment operator:

Rust

fn main() {
  let time = 60;
  time -= 1;
}

fn main() {
  let time = 60;
  time -= 1;
}

Compilation fails. All variables are immutable unless we opt in to mutability. Immutability means we programmers can be certain that a variable is what it was initialized to. We don't need to look anywhere but the initialization for its value. It also means we can share data between tasks with no concern that they'll interfere like two roommates over the microwave. Compilation succeeds once we modify the variable with mut:

Rust

fn main() {
  let mut time = 60;
  time -= 1;
}

fn main() {
  let mut time = 60;
  time -= 1;
}

Now we add a loop:

Rust

fn main() {
  let mut time = 60;
  while time >= 0 {
    time -= 1;
  }
}

fn main() {
  let mut time = 60;
  while time >= 0 {
    time -= 1;
  }
}

There are no parentheses around conditions. If you include them, the compiler will warn you to stop being so noisy.

Let's print:

Rust

fn main() {
  let mut time = 60;
  while time >= 0 {
    println!("{}", time);
    time -= 1;
  }
}

fn main() {
  let mut time = 60;
  while time >= 0 {
    println!("{}", time);
    time -= 1;
  }
}

Rust's format strings are more like Python's than C's. The output looks nice, but we need to slow it down. We call the sleep function, which needs to be imported with a use statement:

Rust

use std::thread;
use std::time::Duration;

fn main() {
  let mut time = 60;
  while time >= 0 {
    println!("{}", time);
    thread::sleep(Duration::from_millis(1000));
    time -= 1;
  }
}

use std::thread;
use std::time::Duration;

fn main() {
  let mut time = 60;
  while time >= 0 {
    println!("{}", time);
    thread::sleep(Duration::from_millis(1000));
    time -= 1;
  }
}

There's no reason it needs to take up so much output. This timer shows both the current time and all the old times. Useless. I don't care about the old times. Let's erase them. We could uses Curses, or we could just print a carriage return to bring the cursor back to the beginning of the line. We'll need print! instead of println!. Since one-digit numbers won't overwrite the second digit, we need to pad them out with a formatting flag:

Rust

use std::thread;
use std::time::Duration;

fn main() {
  let mut time = 60;
  while time >= 0 {
    print!("\r{:<2}", time);
    thread::sleep(Duration::from_millis(1000));
    time -= 1;
  }
}

use std::thread;
use std::time::Duration;

fn main() {
  let mut time = 60;
  while time >= 0 {
    print!("\r{:<2}", time);
    thread::sleep(Duration::from_millis(1000));
    time -= 1;
  }
}

But this switch causes the output to disappear algother. The problem, like always, is unflushed buffers. When we write data, it doesn't go immediately to its destination. Instead it goes to a buffer in RAM. Only when that buffer gets full does it get flushed onward. Or sometimes newlines cause it to flush. Or we can explicitly flush it, which requires some more imports and also error handling:

Rust

use std::thread;
use std::time::Duration;
use std::io::{self,Write};

fn main() {
  let mut time = 60;
  let mut stdout = io::stdout();
  while time >= 0 {
    print!("\r{:<2}", time);
    stdout.flush().unwrap();
    thread::sleep(Duration::from_millis(1000));
    time -= 1;
  }
}

use std::thread;
use std::time::Duration;
use std::io::{self,Write};

fn main() {
  let mut time = 60;
  let mut stdout = io::stdout();
  while time >= 0 {
    print!("\r{:<2}", time);
    stdout.flush().unwrap();
    thread::sleep(Duration::from_millis(1000));
    time -= 1;
  }
}

There's not a global variable for standard out as we see in other languages, so we have to request a handle to it. Most I/O methods, like flush, have the potential to fail. Rust doesn't have exceptions. Instead it uses enums like Option and Result, which add a secondary state to normal return values. We have to acknowledge the multiple variants of a returned value. The unwrap call causes the process to panic if a failure variant is returned. Panic means exit with a bad status code. We'll see other ways of dealing with optional types in our next examples.

Handling Errors

Before we move on to the next exercise, let's our options for dealing with errors. When something goes wrong, we have these possible choices for how to proceed:

Ignore it and proceed—at who knows what peril.
Explicitly crash or panic, as it's called in Rust. Callers are given no chance to recover.
Throw an exception. The current function halts, and the exception bubbles or propagates upward through the call stack. Exceptions aren't necessarily a bad choice, but they complicate programs by adding a secondary but implicit flow to our programs. We already know how to bail from functions: by returning. We already have a way of communicating results to the caller: by returning a value. Why not use the mechanism we already have?
Return a value that has an error variant. Instead of returning an Int, we effectively return an IntOrFailure.

In C, we take either the first approach or set some global error value. In Java, we throw exceptions. In Rust, we use Option. Optional types might seem like a sidewise move compared to exceptions. They seem to accomplish the same goal as exceptions but seemingly add a lot of code. However, there are some advantages to optional types:

Optional types build failure into the type system. The compiler, through its normal typechecking, verifies that we aren't treating a failure as normal data. We won't get accidental null pointer exceptions.
Every function along the error path acknowledges the possibility of failure. There will be no wild jumping like we see with exceptions.

Wc

The Unix utility wc counts characters, words, and lines in a file. We run it from the command-line as wc path/to/file.txt. Let's write our own version in Rust. Instead of diving right into code, work with your neighbors to do some reconnaissance. In particular, answer these questions:

How do we get at the command-line arguments?

How do we read a file all at once into a string?

How do we count the characters in a string?

How do we count the words in a string?

How do we count the lines in a string?

Okay, we're ready to write some code. Let's start by pulling out the path from the command-line arguments.

Rust

use std::env;
use std::fs;

fn main() {
  let args = env::args();
  println!("{:?}", args);
}

use std::env;
use std::fs;

fn main() {
  let args = env::args();
  println!("{:?}", args);
}

The output shows that the executable name is the first parameter. We want the second.

When we call env::args we do not get back a collection. Instead we get an iterator. In Java, iterators have two methods, hasNext and next, that we use to drive forward and eventually terminate. In Rust, we have next but no hasNext. Any guesses why? The next method returns Option. It'll give back the None variant when hasNext would give back false.

To get at the second parameter, we could call next twice. Iterators also have an nth method for fetching the \(n^\textrm{th}\) parameter. Let's call that instead:

Rust

fn main() {
  let path = env::args().nth(1);
  println!("{:?}", path);
}

fn main() {
  let path = env::args().nth(1);
  println!("{:?}", path);
}

The path is wrapped up in an Option variant. Earlier we forced the program to panic if we got a None back. What method did that? unwrap. Instead, we could explicitly handle each variant with a match statement:

Rust

fn main() {
  match env::args().nth(1) {
    Some(path) => println!("{}", path),
    None => panic!("Usage: wc <file>"),
  }
}

fn main() {
  match env::args().nth(1) {
    Some(path) => println!("{}", path),
    None => panic!("Usage: wc <file>"),
  }
}

Neat, but the path is only valid inside the first arm. Do we need to nest all our code inside that arm? Imagine if we had five more calls that returned Option. The nesting would get out of hand. Sequences are easier to read than nesting, so let's switch to a match expression that yields the path to the outer scope:

Rust

fn main() {
  let path = match env::args().nth(1) {
    Some(path) => path,
    None => panic!("Usage: wc <file>"),
  };
}

fn main() {
  let path = match env::args().nth(1) {
    Some(path) => path,
    None => panic!("Usage: wc <file>"),
  };
}

The second arm exits the process, so it doesn't return anything.

This pattern of trying to get a value and panicking if it's bad is common enough that there's a helper function that abstracts it away. It's expect:

Rust

fn main() {
  let path = env::args().nth(1).expect("Usage: wc <file>");
}

fn main() {
  let path = env::args().nth(1).expect("Usage: wc <file>");
}

That's much easier to read. Let's hand the path off to a function that reads in the file and computes its statistics. We'll have that function return an instance of this struct:

Rust

#[derive(Debug)]
struct Statistics {
  character_count: usize,
  word_count: usize,
  line_count: usize,
}

#[derive(Debug)]
struct Statistics {
  character_count: usize,
  word_count: usize,
  line_count: usize,
}

Then we frame our helper function. It takes in a borrowed string and gives back an instance of our struct:

Rust

fn count(path: &str) -> Statistics {
  // ...
}

fn count(path: &str) -> Statistics {
  // ...
}

The main function will call count like this:

Rust

fn main() {
  let path = env::args().nth(1).expect("Usage: wc <file>");
  let statistics = count(&path);
  println!("{:?}", statistics);
}

fn main() {
  let path = env::args().nth(1).expect("Usage: wc <file>");
  let statistics = count(&path);
  println!("{:?}", statistics);
}

Inside count we need to read the file. That might fail. For the moment, let's panic if that reading fails:

Rust

fn count(path: &str) -> Statistics {
  let text = fs::read_to_string(path).expect("Couldn't read file.");
  // ...
}

fn count(path: &str) -> Statistics {
  let text = fs::read_to_string(path).expect("Couldn't read file.");
  // ...
}

Most Rust collections have a len method reporting their number of elements. We can use it to get the number of bytes in the string, which is not quite the same as the number of characters. Function split_whitespace gives us an iterator over words, and function lines gives us an iterator over the lines. Iterators don't have a len method, but they do have count. With these methods, we compute our statistics:

Rust

fn count(path: &str) -> Statistics {
  let text = fs::read_to_string(path).expect("Couldn't read file.");

  Statistics {
    character_count: text.len(),
    word_count: text.split_whitespace().count(),
    line_count: text.lines().count(),
  }
}

fn count(path: &str) -> Statistics {
  let text = fs::read_to_string(path).expect("Couldn't read file.");

  Statistics {
    character_count: text.len(),
    word_count: text.split_whitespace().count(),
    line_count: text.lines().count(),
  }
}

Flashmod

For our last example, let's make a math flashcard quizzer. We're all good enough at addition and multiplication. Our flashcards will be for modular division. Rust doesn't ship with a library for generating random numbers, so we have to install a package. As soon as a project has dependencies, we are better off using its package manager Cargo than using rustc directly. We build a new Cargo project and add the third-party rand and text_io crates (libraries) with these shell commands:

Shell

cargo new flashmod
cargo add rand text_io

cargo new flashmod
cargo add rand text_io

In src/main.rs we add code to generate and print two random numbers:

Rust

use rand::Rng;
use std::io::{self,Write};
use text_io::read;

fn main() {
  let mut generator = rand::rng();
  let mut stdout = io::stdout();

  let a = generator.random_range(0..50);
  let b = generator.random_range(1..10);

  print!("{} % {} = ", a, b);
  stdout.flush().unwrap();
}

use rand::Rng;
use std::io::{self,Write};
use text_io::read;

fn main() {
  let mut generator = rand::rng();
  let mut stdout = io::stdout();

  let a = generator.random_range(0..50);
  let b = generator.random_range(1..10);

  print!("{} % {} = ", a, b);
  stdout.flush().unwrap();
}

Since there's no newline, we flush the output. Let's give the user ten problems with a for loop:

Rust

fn main() {
  let mut generator = rand::rng();
  let mut stdout = io::stdout();

  for _ in 0..10 {
    let a = generator.random_range(0..50);
    let b = generator.random_range(1..10);

    print!("{} % {} = ", a, b);
    stdout.flush().unwrap();
  }
}

fn main() {
  let mut generator = rand::rng();
  let mut stdout = io::stdout();

  for _ in 0..10 {
    let a = generator.random_range(0..50);
    let b = generator.random_range(1..10);

    print!("{} % {} = ", a, b);
    stdout.flush().unwrap();
  }
}

We don't name the loop element because we never reference it. Next we get input from the user. User input is a little clumsy in Rust, so let's use the text_io crate to make it simpler. It has the polymorphic read! macro that will grab a string and parse it according to the type imposed by the context.

Rust

fn main() {
  let mut generator = rand::rng();
  let mut stdout = io::stdout();

  for _ in 0..10 {
    let a = generator.random_range(0..50);
    let b = generator.random_range(1..10);

    print!("{} % {} = ", a, b);
    stdout.flush().unwrap();

    let response: i32 = read!();
  }
}

fn main() {
  let mut generator = rand::rng();
  let mut stdout = io::stdout();

  for _ in 0..10 {
    let a = generator.random_range(0..50);
    let b = generator.random_range(1..10);

    print!("{} % {} = ", a, b);
    stdout.flush().unwrap();

    let response: i32 = read!();
  }
}

All that remains is a final conditional to give feedback to the user:

Rust

fn main() {
  let mut generator = rand::rng();
  let mut stdout = io::stdout();

  for _ in 0..10 {
    let a = generator.random_range(0..50);
    let b = generator.random_range(1..10);

    print!("{} % {} = ", a, b);
    stdout.flush().unwrap();

    let response: i32 = read!();

    if a % b == response {
      println!("That's exactly right.");
    } else {
      println!("Well, no.");
    }
  }
}

fn main() {
  let mut generator = rand::rng();
  let mut stdout = io::stdout();

  for _ in 0..10 {
    let a = generator.random_range(0..50);
    let b = generator.random_range(1..10);

    print!("{} % {} = ", a, b);
    stdout.flush().unwrap();

    let response: i32 = read!();

    if a % b == response {
      println!("That's exactly right.");
    } else {
      println!("Well, no.");
    }
  }
}

That concludes our first tour of Rust. It sits somewhere between Ruby and Haskell. The compiler knows the types, so it can perform typechecking. Values can be mutable, so we don't have to contort ourselves into recursion like we did in Haskell. It's got a rich standard library and a very friendly package manager and build tool in Cargo. It's hip. It's supposed to make software safer. It forces you to contend with errors either by explicitly panicking or by handling the error variants of returned values.

TODO

Here's your list of things to do before we meet next:

Complete the middle quiz as desired.

Get a Rust compiler installed. See instructions in the HOWTO in the book.

There are two ready dates remaining. These last two effectively are extensions. Further extensions will not be granted.

See you next time.

Sincerely,

P.S. It's time for a haiku!

A master language? Which will replace all others? They'd call it !C

← Vectors Lab: Rust Mains →

Dear Computer

Lecture: Everything Revisited

Countdown

Handling Errors

Wc

Flashmod

TODO