for_each, map, and compiler warnings

Rust has a great attribute you can add to structs called must_use. It is used on the Result<T, E> enum in the standard library, which looks like this:

#[derive(Clone, Copy, PartialEq, PartialOrd, Eq, Ord, Debug, Hash)]
#[must_use = "this `Result` may be an `Err` variant, which should be handled"]
#[stable(feature = "rust1", since = "1.0.0")]
pub enum Result<T, E> {
    /// Contains the success value
    #[stable(feature = "rust1", since = "1.0.0")]
    Ok(#[stable(feature = "rust1", since = "1.0.0")] T),

    /// Contains the error value
    #[stable(feature = "rust1", since = "1.0.0")]
    Err(#[stable(feature = "rust1", since = "1.0.0")] E),

And on std::iter::Map, it looks like this:

#[must_use = "iterator adaptors are lazy and do nothing unless consumed"]
pub struct Map<I, F> { /* fields omitted */ }

So what does this attribute do? From the docs:

must_use – on structs and enums, will warn if a value of this type isn’t used or assigned to a variable. You may also include an optional message by using #[must_use = "message"] which will be given alongside the warning.

Continue reading “for_each, map, and compiler warnings”

Fixing a Simple Lifetime Error in Rust

Lifetimes are perhaps the hardest thing to understand when first approaching Rust. Today I’m going to create a lifetime error and demonstrate two strategies for fixing it. If you’re very new to rust, you may wish also to read the (beautifully titled) post Rust Lifetimes for the Unitialised first, as well as Strategies for Returning References in Rust.

To get started, we’re going to consider two Ruby implementations that are equivalent:

# first version
my_collection =
(1..10).each do |item|
value = "value number #{item + 1}"
# second version
my_collection =
values = []
(1..10).each do |item|
value = "value number #{item + 1}"
values.each { |v| my_collection.insert(v) }

view raw


hosted with ❤ by GitHub

Continue reading “Fixing a Simple Lifetime Error in Rust”

Investigating Performance Changes with git bisect

This week, I have been working an issue with LALRPOP. Basically, at some point there was a performance degradation on a newer version of the library. Niko Matsakis mentioned that this is likely due to failing to cache some regular expressions that we need repeatedly. I assume he’s correct, but I want to understand how this performance degradation was introduced, and I’m very new to this code base, so I’m going to try to find the change that introduced it. To find this change, I will use a tool called git bisect. Continue reading “Investigating Performance Changes with git bisect”

Calculator REPL Part 3: Evaluating the tokens

This is the third and final part of a series on building a simple calculator REPL in Rust. (You may with to read part one and part two first.)

Here we’re going to talk about the eval function, which takes an array of tokens, and either returns the result of the calculation or an error. You may have noticed that I used Polish notation, e.g., + 3 4 in this language, with the expressions delimited by parentheses. The reason for this is two-fold: First, I want to make this into a more full-featured Lisp interpreter one day, and second, for the same reason that Lisp is written in prefix notation – it makes things easy to parse. As wikipedia says:

When Polish notation is used as a syntax for mathematical expressions by programming language interpreters, it is readily parsed into abstract syntax trees and can, in fact, define a one-to-one representation for the same. Because of this, Lisp (see below) and related programming languages define their entire syntax in terms of prefix notation (and others use postfix notation).

We can think of an expression like (* (+ 2 3) (+ 1 3)) as a tree, with the division operator at the root and (+ 2 3) and (+ 1 3) as sub-trees. One major difference in the language I’ve defined from Polish mathematical notation is that I allow an arbitrary number of operands to follow each operator, which is why I need parentheses. Continue reading “Calculator REPL Part 3: Evaluating the tokens”

How can I help Stabilize Things?

A friend and I are working on adding Rust support to Metaparticle.

We did a simple search for “decorators in Rust” and found this repo, which seemed promising. My friend added it, but soon found it wouldn’t build without using the nightly channel of rustc. I didn’t notice right away, because I like to experiment with Rust and have been running nightly by default for months, but my friend found this very off-putting. From his perspective, it seems like he can’t adopt Rust yet, because too many libraries require nightly, which makes it seem like the language isn’t production-ready yet. Continue reading “How can I help Stabilize Things?”

Fun with Fixed Points

Today we’re going to have fun with fixed points. A fixed point of a function f is the value x such that f(x) = x. Not everyone function has a fixed point. For example, f(x) = x + 1 has no fixed point. But many functions do. Cosine is one such function. Today we’re going to write code that finds the fixed point of the cosine function. Continue reading “Fun with Fixed Points”

Broken Pipe

I’m writing a simple utility called wires. It’s a clone of the GNU utility strings, but it’s written in Rust so I wanted the name to be more metallic. I had a working build now (though it doesn’t quite have all the flags and features of the original), and I thought everything was fine, but then I piped the output to head -10. And I immediately got this:

thread 'main' panicked at 'Failed to write to supplied stream: 
    Error { repr: Os { code: 32,message: "Broken pipe" } }', src/libcore/
note: Run with `RUST_BACKTRACE=1` for a backtrace.

Hmm, that’s not very friendly. Unix-y command line tools should be able to redirect output to each other without crashing. Continue reading “Broken Pipe”


I like retro games, so I’m trying to write a Zork machine in Rust. That said, I’m brand new to Rust, so I’ve decided to take smaller bites of the language until I’m a little bit more comfortable with how it works. This post is the story of one of these smaller projects.

Enter wires, a (much simplified) tool in Rust similar to the GNU utility Strings. Wires consumes a file, one byte at a time. If it finds a series of bytes at least 3 bytes long, where every byte is a printable ASCII character, it writes the series to stdout. If it can’t find or open the file, it exits 1, and if writing to stdout fails, it panics. Not super complicated, but it’s finished and does just that. Continue reading “Wires”

Counting Fruit in Rust, Part 2

This is the third part of a series on beginning rust. You may wish to read part 1 and part 2 first.

I want to be able to visit all the nodes of a tree in Rust. Last time, I showed the implementation of the tree itself, and code that would generate a random tree. This time, I’m going to show and describe code for walking around a tree and counting which nodes have a flag set. The code we’ll talk about this episode is here: Continue reading “Counting Fruit in Rust, Part 2”

Counting Fruit in Rust

Last time, I mentioned that I was starting up Rust again, and mentioned some helpful videos and thoughts that will help me as I take another swing at learning this language. The complete source for the examples I’ll use today is on GitHub, and you should be able to download it and cargo run without much trouble. If you don’t have Rust and Cargo, you want to install rustup first.

Today, we’re going to generate a random tree, then we’re going to walk the tree recursively and count which nodes have a flag set. Here’s the code for representing the nodes and generating the tree: Continue reading “Counting Fruit in Rust”