<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

<h1>The Best 25 Bucks I Ever Spent</h1>
Earlier this year (I don't remember the exact day or month) I decided, screw it, I'm going to try using a flip phone.
For years I've wondered what it was like before the information revolution, but <a href="https://en.wikipedia.org/wiki/Generation_Z">as a Zoomer</a>, I've never had the opportunity.
I got the cheapest Verizon-compatible flip phone Amazon had to offer and I committed myself to using it exclusively for at least a week.
A week without the entirety of human knowledge in my pocket.
A week of using my voice to communicate, rather than a touch-screen keyboard.
<img src="/images/flip_phone.jpg" alt="The phone in question">
Beside two factor authentication for GitHub, that first week was a breeze.
I found myself socializing more, since it turns out that most people in my social circle are just a phone call and a 10-minute walk away.
I also found myself reading better quality literature.
Rather than resorting to HackerNews to ease my boredom, I began devouring full books at a frightening pace.
That first week turned into two, then four, then twelve.
All the while, I was proving to myself that I didn't need a smartphone.
For a number of reasons, I'm back to using a smartphone.
But this experience has taught me some important lessons that I don't think can be taught any other way.
Organizing social encounters over text just doesn't work.
Some people don't check their phone too often.
Calling them make it clear that their participation is important to you.
This may sound trivial or obvious to some of the older members of my audience, but to pretty much every Zoomer I've talked to about this, it is a revelation.
Quiet is sacred, and should be protected.
I see loads of people who walk around every day with their headphones in, barely paying attention to the music blaring out of them.
I've done this myself.
It closes you off the world.
From the tapping of water off an icicle.
From the shaky but warm greeting from a colleague.
From the chortling roar of an engine.
But most of all, it closes you off from your own mind.
The best thinking and imagining happens in the quiet, when your brain has nothing more stimulating to do.
Overall, using a flip phone was a very quieting experience.
It helped the world feel larger and more magical.

The Best 25 Bucks I Ever Spent

<h1>Code Ages Like Milk</h1>
<img src="/images/front_range.webp" alt="The Front Range in the summer is hard to beat">
A bold title, no? But it’s true, and it’s something that I (and most other maintainers) have to deal with on a regular basis. Failing to account for this reality can slow down development and dissuade contributors from sticking around.
As the chief maintainer of Harper, one of my main jobs is to act as quality control. I receive <a href="https://github.com/Automattic/harper/pulse/monthly">a number of PRs each week</a>, both from new contributors and old. Given the diverse pool of contributors, it makes sense that I review a diverse pool of code of varying levels of quality.
When I have my head down on technical and attention-intense projects, I have less time to review code. When I have less time, I need to set priorities. The question becomes: Would I rather let code from high-quality, reliable sources pile up, or code from sources of unknown quality?
I usually end up reviewing the high-quality sources first, since they’ll likely require fewer revisions. Fewer revisions means quicker merge means improving the user experience faster. Whether or not this is a good decision is something I’ve been thinking about all week.
<h2>Code Ages</h2>
As code sits stagnant in a PR, it ages. You might say I’m crazy, that there is no way the code itself changes as it sits still in an unmerged and unmodified PR. I’d say you’re right, except for one teeny-tiny detail: Code only has meaning when it sits within a broader context. If that broader context changes (for example, when other PRs are merged) the meaning of the unmodified code does too.
Let me put it another way. If the patch from a PR remains stagnant, but the code it gets patched onto changes, the actual impact of the patch does too. This can cause all sorts of problems, from merge conflicts to erroneous test failures.
The longer code sits in a PR, the more time it usually ends up taking me to get it merged (when I finally have the time to get to it), just from the merge conflicts alone. It’s the Lindy effect rearing its ugly head once more.
<h2>Features Age Too</h2>
Not only does code age when left untouched and unused, so do the features they represent. If a user requests for a button that marks some text as bold and they don’t receive that feature promptly, they’ll find an alternative solution, possibly from a competitor.
The rest of the app can evolve too. If you’re an individual contributor, it’s in your best interest for your code to make it to master. If that doesn’t happen quickly enough, another contributor (or, if the software is extensible, like Obsidian or WordPress) or plugin author might beat you to the punch.
<h2>What Can I Do About It?</h2>
I believe the way I’ve been handling this until now has been entirely wrong. I should be allocating more of my time to training new contributors and fielding PRs from established ones. Open sources is a team effort.
As for you, dear reader, that’s for you to figure out. The worst way code can age is if it stays in your head. Don’t let your ideas go to waste. <a href="./never_wait.md">Open that PR</a>, or remind your reviewer to take another look if you haven’t already.

Failing to account for this reality can slow down development and dissuade contributors from sticking around.

Failing to account for this reality can slow down development and dissuade contributors from sticking around.

Code Ages like Milk

speaking_at_wordcamp_u.s._in_2025

<h1>Speaking at WordCamp U.S. in August</h1>
I was recently encouraged to submit a talk proposal to the AI track at WordCamp US.
I was more than happy to oblige, and to my surprise, I got in.
See description below for details. I hope to see some of y'all there!
<img src="/images/wordcamp_us_speaker_2025.png" alt="I&#x27;ll be speaking at WordCamp US 2025">
<h2>Description</h2>
Machine learning has been around for decades.
Until recently, running ML models typically required big centralized servers due to high computational demands.
With modern hardware and tools like Rust and Burn, we can flip the script.
When run on a user's device, trained models can be an incredible boost to human creativity and expression.
Harper is a grammar checker that is designed to improve your work without degrading your integrity—or the writing experience itself.
Our users generate and publish novel ideas faster because we focus on what's important: speed, privacy, and accuracy.
WordPress' mission is to democratize publishing.
This talk will explore how we can use AI to democratize writing too.
More importantly, how you can train and deploy specialized models at the edge to eliminate inference costs, lower latency, and improve user satisfaction.

I was recently encouraged to submit a talk proposal to the AI track at WordCamp US. I was more than happy to oblige, and to my surprise, I got in.

I was recently encouraged to submit a talk proposal to the AI track at WordCamp US. I was more than happy to oblige, and to my surprise, I got in.

Elijah Potter

Speaking at WordCamp U.S. in August

Description

Other Stuff

Build a Wordle Solver Using Rust

The Best 25 Bucks I Ever Spent

Code Ages like Milk