<h1>Build a Wordle Solver Using Rust</h1>
<h2>The Game</h2>
<a href="https://www.nytimes.com/games/wordle/index.html">Wordle</a> is a relatively simple game. If you have ever played Mastermind, it should sound familiar. The goal is to figure out a mystery word with as few guesses as possible. The mystery word changes each day. Here are two example guesses.
<img src="/images/wordle_example.png" alt="Two example guesses from the game Wordle">
After a guess, each letter’s color changes.
Green — The letter is correct.
Yellow— The letter exists in the word, but not in that space.
Gray — The letter does not exist in the word.
As you can see, there are a maximum of six guesses. If you cannot find the mystery word within six guesses, you lose. I have been competing with my grandmother each day to find the word in as few guesses as possible.
<img src="/images/xkcd_nerd_sniping.png" alt="XKCD Comic #356">
This totally nerd-sniped me. I felt an overwhelming urge to build an app that could, conceivably find the mystery word in as few guesses as possible.
<h2>How I Did It</h2>
First things first, we need a list of English words. I initially used the <a href="http://www.mieliestronk.com/wordlist.html">corncob</a> list, but I found greater success with <a href="https://github.com/dwyl/english-words/">dwyl’s</a> list.
For this project, I decided to use Rust, just because I felt most confident in my ability to make an MVP quickly.
Both the word lists I used are formatted as a sequence of individual words, separated by <code>\n</code> characters. On Windows (which is what I am using), they also have pesky those little <code>\r</code> characters.
Wordle is heavily focused on letters. I can remove items from the word list based on what letters I know aren’t in the mystery word (these are gray letters in-game), and I can remove items based what letters I know are in the mystery word (the orange or green letters), but in a lot of cases that still leaves a lot of possible words. I need to way to sort words based on how likely their letters are.
To do this, I count how frequently each letter appears in the word list, and give each word a score based on how frequently its components appear.
The first step in the program is to load the word list and count the letters:
<pre><code class="hljs language-rust">// Store the total number of times a letter appears.
let mut letter_scores = HashMap::new();
// The final list of words. It will make like easier later in the program to store the words as Vec&#x3C;char>.
let mut word_list = Vec::new();
let mut last_word = Vec::new();
let file = std::fs::read("corncob_lowercase.txt")?;

// Iterate through all the bytes in the wordlist file, ignoring all `\r` instances.
for letter in file {
 let letter = letter as char;
 match letter {
 '\n' => {
 word_list.push(last_word);
 last_word = Vec::new();
 }
 '\r' => (),
 _ => {
 let entry = letter_scores.entry(letter).or_default();
 *entry += 1;
 last_word.push(letter);
 }
 }
}
</code></pre>
Using the default <code>HashMap</code> (which uses <code>SipHash</code>, which isn’t great for single-character lookup), probably isn’t the best, performance-wise, but this is just a toy program, and doesn’t need to be the fastest thing in the world.
Next, we need to go through the word list, and eliminate words that contain gray letters. Here is a function that helps do that:
<pre><code class="hljs language-rust">fn matches_found(
 word: &#x26;[char],
 found: &#x26;[char],
 not: &#x26;[char],
 must: &#x26;[char],
 masks: &#x26;[Vec&#x3C;char>],
) -> bool {
 // Check if the word contains a letter we know *isn't* in the mystery. &#x3C;-- The gray letters.
 for c in not {
 if word.contains(c) {
 return false;
 }
 }

 // Check if the word contains the letters we don't know the positions of, but know they are in the mystery word.. &#x3C;-- The orange letters.
 let mut found_letters = 0;
 for c in must {
 if word.contains(c) {
 found_letters += 1;
 }
 }
 if found_letters &#x3C; must.len() {
 return false;
 }

 // Check if the word has letters we know exist in the word, but not at the right spots. &#x3C;-- The orange letters.
 for mask in masks {
 for i in 0..min(word.len(), mask.len()) {
 if word[i] == mask[i] {
 return false;
 }
 }
 }

 // Check if the word contains the already found (green) letters.
 for i in 0..min(word.len(), found.len()) {
 if found[i] != ' ' &#x26;&#x26; word[i] != found[i] {
 return false;
 }
 }

 true
}
</code></pre>
It accepts a few different char slices:
<ul>
<li>Word: the word we want to check.
Found: this is a slice containing the letters we have found (the green ones), with “ “ (space) characters in the locations we don’t know the character of.</li>
<li>Not: this is a slice containing the letters we know aren’t in the mystery word.</li>
<li>Must: this is a slice containing the letter we know are in the mystery word, but we don’t know the position of.</li>
<li>Masks: this is a series of masks. We remove every word that has letters that match any mask here. This is useful for eliminating words in the wordlist that contain punctuation and for eliminating words that contain orange letters, but in positions we know they aren’t.</li>
</ul>
Now all we have to do is run each word in the word list and see if it matches our already known characters, updating the contents of each slice with new information after each guess.
<h2>Why You Should Care</h2>
This sounds like a useless problem. It is. There is no way this will benefit anyone other than me, and I definitely won’t use this when I’m actually competing with my grandmother.
Then why did you do it?
Useless answers to useless problems are useful. They teach us how to improve, without the pressure of real stakes. They are also just plain fun.
It’s also a reflection. How would you have approached this problem in the past? How has your thinking improved. Maybe it’s a bit magnanimous to say this little Wordle solver is the key to self reflection, but I don’t think it’s that far off.
<hr>
<h2>A Reflection From Months Later</h2>
Hi! I am returning to this project months later with a few thoughts.
When I first wrote this article, I completely neglected to share my fitness test for each word. In hindsight, it's a good thing I didn't. It was the exact method 3Blue1Brown described as "naive" in his (fantastic) <a href="https://youtu.be/v68zYyaEmEA">video</a> on this very topic.

I built a Wordle solver in Rust to beat my grandma. Follow the journey of how I did, and how I failed.

I built a Wordle solver in Rust to beat my grandma. Follow the journey of how I did, and how I failed.

Build a Wordle Solver Using Rust

It didn't work for me, and if you reading this, it probably won't work for you either.

It didn't work for me, and if you reading this, it probably won't work for you either.

Do Not Type your Notes

<h1>The One Hard Thing</h1>
People (myself included) love to make cascading lists of tasks.
Actions, each of which are needed to improve a product, release a feature, or manage people.
These lists tend to explode in size, as more is asked of you.
There's one problem: I have only eight hours in a working day.
With so little time, how can I be expected to both maintain existing projects (bug fixes, etc.) while consistently delivering new functionality and maintaining a fast iterative loop?
<h2>Insight</h2>
I've had two key insights that have led to some tremendous personal productivity gains.
First: I've observed that the difficulty of my tasks tends to follow a <a href="https://en.wikipedia.org/wiki/Pareto_distribution">Pareto distribution</a>.
A small number of tasks are shockingly difficult to solve, while a much larger set boil down to communication.
Second: the morning is my most productive time of day.
For some reason, I'm able to tackle problems with an otherwise unusual mental clarity.
I suspect it's something to do with the natural human circadian rhythm or digestion.
<h2>Leveraging the Pattern</h2>
Motivated by these two observations, I've developed a habit: I dedicate each morning to its own difficult problem.
This is a single task that is chosen specifically to stretch my limits.
I call this my daily one hard thing.
Previous examples:
<ul>
<li>Developing the first version of <a href="https://writewithharper.com/docs/integrations/language-server"><code>harper-ls</code></a> which is now used by thousands of developers daily.</li>
<li>Building the first 80% of the <a href="https://writewithharper.com/docs/integrations/obsidian">Harper Obsidian plugin</a>, which is also widely used.</li>
<li>Grokking how <a href="https://github.com/Automattic/jetpack"><code>Jetpack's Write Brief with AI</code></a> feature works (before I joined Automattic).</li>
<li>Compiling Harper to WebAssembly and embedding it somewhere no one has put a grammar checker before: inside the web browser.</li>
</ul>
<h2>Think About It</h2>
I implore you: think about how you work.
How is your energy affected by the things you do in the day-to-day?
If you enjoy your eight hours, maybe the rest will be better too.

Reach further each day. The minimum effective dose.

Reach further each day. The minimum effective dose.

The One Hard Thing

why_you_need_sccache

<h1>Why You Need <code>sccache</code></h1>
As the maintainer of a <a href="https://writewithharper.com">reasonably popular open source project</a> written in Rust, I find myself cloning PRs and swapping between branches dozens of times a day.
In doing so, I often blow away Rust's compilation cache either via <code>git clean -xf .</code> or by changing dependency versions.
Having a build cache that is separate from the project is a huge win for compile times, which is why I use <a href="https://github.com/mozilla/sccache"><code>sccache</code></a>.
For those unaware, <code>sccache</code> is a build tool for C, C++ and Rust projects that stands in front of the compiler.
If a given file's hash is the same across calls to the compiler, <code>sccache</code> reuses the previous result.
This cache is compiler–and project agnostic.
In my case, it sits in <code>$HOME/.scccache</code>, but you can set it up with AWS S3, Redis or a myriad of other options.
If a dependency is cached from a compile in one project, it is available for a build in another.
In short: you need <code>sccache</code> if you are frequently swapping between branches with similar (but not identical) dependencies or expect to frequently delete Rust's disk cache.
<h2>Why You Don't Need <code>sccache</code></h2>
If you are working in a single branch on a project whose dependencies remain somewhat stable, <code>sccache</code> might actually increase your compile time.
Since <code>sccache</code> has to hit the disk (or even the network) regardless of whether it is a cache hit, a little bit of latency is added.
If you expect most compiles to be cache hits or most compiles to be cache misses, <code>sccache</code> is no more useful than the built-in caching <code>cargo</code> provides.
In that case you should not use <code>sccache</code>.
<h2>Wrap-Up</h2>
Regardless of whether you install <code>sccache</code> on your machine, it is a neat little technology.
I would recommend the curious reader take a look for themselves.
You might be inspired.

Elijah Potter

Why You Need `sccache`

Why You Don't Need `sccache`

Wrap-Up

Other Stuff

Build a Wordle Solver Using Rust

Do Not Type your Notes

The One Hard Thing

Elijah Potter

Why You Need sccache

Why You Don't Need sccache

Wrap-Up

Other Stuff

Build a Wordle Solver Using Rust

Do Not Type your Notes

The One Hard Thing

Why You Need `sccache`

Why You Don't Need `sccache`