<h1>Stupid-Simple Spell-Check</h1>
<img src="/images/antiques.webp" alt="A sign advertising for antiques, but misspelled.">
For the last month, I've been spending a lot of time replacing one key component
of my writing and programming environment: my grammar checker.
Up until now, I've been using the eponymous <a href="https://languagetool.org/">LanguageTool</a>
via <a href="https://github.com/valentjn/ltex-ls"><code>ltex-ls</code></a> and <a href="https://github.com/neovim/nvim-lspconfig"><code>nvim-lspconfig</code></a>.
Don't get me wrong, these tools are really good, and I would recommend them to anyone and everyone.
However, they come with a few key annoyances.
<h2>LanguageTool Grievances</h2>
<h3>Performance</h3>
LanguageTool is slow.
I'm not exactly sure why.
Every time I would run LanguageTool over my Markdown or <math xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mtext>LaTeX</mtext></mrow><annotation encoding="application/x-tex">\LaTeX</annotation></semantics></math>LATE​X documents (which are reasonably sized),
I would have to wait several seconds before even the rudimentary spell-checking would show up.
Additionally, I would find <code>ltex-ls</code> regularly becoming the most memory-hungry application on my laptop,
often exceeding 4 gigabytes.
After hours of scouring their code base, I have come to no better explanation
than that it is written in Java.
There are a couple questionable algorithmic decisions in there as well.
<h3>Download Size</h3>
As I said: LanguageTool is really quite good.
However, to get everything it can offer, you need to not only install a Java Runtime
Environment (>150 MB on my system), the actual <code>.jar</code> file (>300 MB), but you also need to download
a 16 GB n-gram dataset.
<h2>Grammarly Grievances</h2>
"But Elijah," I hear you say, "just use Grammarly!"
No. I'm not going to drop $12 a month for something even slower and worse.
Not to mention how they are likely going to use my work to train their large language models.
Grammarly is a great product, just not for me.
<h2>The Algorithm</h2>
Now that I've thoroughly explained my reasoning for implementing a new grammar checker (one that I'm calling <a href="https://github.com/elijah-potter/harper">Harper</a>), I'd like to recount
my first, admittedly naive, attempt at spellchecking.
The first idea we need to get a grip on is Levenshtein edit distance.
In essence, edit distance is the least number of single-character edits (insertions, deletions or replacements) necessary to turn one word into another.
For example, the edit distance between "cat" and "bat" is one; the only edit involves replacing the "c" with a "b".
Similarly, the edit distance between "kitten" and "sitting" is three: remove the "g", replace the second "i" with an "e" and replace the "s" with a "k".
For this naive spellchecking, we aren't too concerned with the exact edits (atomic errors) that occur in a given misspelling, only the magnitude of the error.
From a high level view here's how the algorithm is going to work:
<ol>
<li>Determine whether a given word is misspelled.
If not, exit.</li>
<li>Calculate the Levenshtein edit distance between the misspelled word and all valid English words.</li>
<li>Pick the three words with the shortest edit distance and present them to the user as alternative
spelling options.</li>
</ol>
<h3>Step 1.</h3>
To determine whether a given word is misspelled, we will need a list of all the valid words in the English language.
Turns out, this isn't too easy.
For today, we will just use a subset of the English language with this short list:
<pre><code>into
the
a
cat
tree
jumped
</code></pre>
To check if a given word is within the list, we can place the list into a hash set,
and grab it's contents.
<pre><code class="hljs language-rust">let words: Vec&#x3C;String> = vec!["into", "the", "a", "cat", "tree", "jumped"]
 .into_iter()
 .map(|s| s.to_string())
 .collect();

let word_set: HashSet&#x3C;String> = words.iter().cloned().collect();

let word = "thw";
let word_chars: Vec&#x3C;_> = word.chars().collect();

if word_set.contains(word) {
 println!("It is a valid English word!");
 return;
}

println!("Are you sure you meant to spell \"{}\" that way?", word);
</code></pre>
<h3>The Wagner-Fischer Algorithm</h3>
Now that we know our word is actually misspelled, we can move on to finding the correct spelling.
We need to find the edit distance between the misspelled word and all the words in our set.
To do this, we will be using the <a href="https://en.wikipedia.org/wiki/Wagner%E2%80%93Fischer_algorithm">Wagner-Fischer</a> algorithm.
<pre><code class="hljs language-rust">// Computes the Levenstein edit distance between two patterns.
// This is accomplished via the Wagner-Fischer algorithm
fn edit_distance(source: &#x26;[char], target: &#x26;[char]) -> u8 {
 let m = source.len();
 let n = target.len();

 // Create an m-by-n matrix.
 let mut d = create_empty_matrix(m + 1, n + 1);

 // Since we know we can transform each word into the other by replacing
 // successive characters (or deleting them), we can fill the first column and
 // row with values from 0..m and 0..n, respectively.
 for i in 0..=m {
 d[i][0] = i as u8;
 }

 for i in 0..=n {
 d[0][i] = i as u8;
 }

 for j in 1..=n {
 for i in 1..=m {
 // The total edit distance of two given letter indices i and j, one from each word
 // will be the sum of the edit distances of prior combinations + whether the characters
 // at the two indices are equal.

 let cost = if source[i - 1] == target[j - 1] { 0 } else { 1 };
 d[i][j] = (d[i - 1][j] + 1)
 .min(d[i][j - 1] + 1)
 .min(d[i - 1][j - 1] + cost);
 }
 }

 // After all possible edits have been explored and minimized
 // the resulting minimum edit distance will be in the final item in the matrix.
 d[m][n]
}

// Create an empty matrix of size [m, n]
fn create_empty_matrix(m: usize, n: usize) -> Vec&#x3C;Vec&#x3C;u8>> {
 let mut d = Vec::with_capacity(m);

 for _ in 0..m {
 d.push(vec![0u8; n]);
 }

 d
}
</code></pre>
This works pretty well.
There are a number of optimizations we could apply to this function alone.
I'll leave that as a problem for the reader, since they aren't particularly relevant to the meat of the larger algorithm.
<h3>Steps 2 + 3</h3>
Now that we can determine the edit distance between two words, we can perform a brute-force search.
In this short example, we're going to use <code>sort_by_key</code> to do this, since our data set is so small.
If we were working with a larger dictionary (say, the entire English language), there would be a number of things we would need to do to reduce time and memory consumption.
<pre><code class="hljs language-rust">let mut suggestions: Vec&#x3C;(String, u8)> = words
 .into_iter()
 .filter_map(|possible_word| {
 let possible_chars: Vec&#x3C;_> = possible_word.chars().collect();

 let dist = edit_distance(word_chars.as_slice(), &#x26;possible_chars);

 if dist &#x3C;= 2 {
 Some((possible_word, dist))
 } else {
 None
 }
 })
 .collect();

suggestions.sort_by_key(|(_, d)| *d);

println!("Possible alternatives: ");

suggestions.iter().for_each(|(s, _)| println!("- {}", s));
</code></pre>
If we run the whole program again, we get an output something like:
<pre><code class="hljs language-output">Are you sure you meant to spell "thw" that way?
Possible alternatives:
- the
</code></pre>
That looks pretty good to me!
If you would like to look at the whole program, and maybe try out your own inputs, <a href="https://play.rust-lang.org/?version=stable&#x26;mode=debug&#x26;edition=2021&#x26;gist=fb7910ad1fb3a6c944cbc2ae8659bb31">go right on ahead</a>.

It almost feels wrong. Maybe it is.

Stupid Simple Spell Check

<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>Footguns of the Rust WebAssembly Target</h1>
<img src="/images/rail.webp" alt="A trail in Golden, Colorado">
WebAssembly—even after several years of standardization—is still a nascent technology.
I've been working with Rust and WebAssembly for nearly four years now.
This post is intended to be a distillate of that experience, formatted for developers who are interested in publishing WebAssembly code to npm.
Specifically, these are the footguns I've personally encountered while working on <a href="https://writewithharper.com/docs/harperjs/introduction"><code>harper.js</code></a>, a WebAssembly-powered package for grammar checking at the edge.
This page should be valuable if you are even speculating on the possibility of using WebAssembly in your codebase.
<hr>
<h2>1. Exposing Only Synchronous Functions</h2>
The Harper package exposes one interface that captures all of its WebAssembly interactions: the Linter. This is an object that handles downloading and compiling the Harper WebAssembly module, as well as invoking functions in it. Every function returns a <code>Promise</code>. There are several good reasons for that:
<ul>
<li>WebAssembly modules larger than 4 kilobytes must be instantiated asynchronously to avoid blocking the event loop during download or compilation. This is a technical limitation that cannot be avoided with clever logic.</li>
<li>If most functions are asynchronous, you can centralize computation and caching into a single instance of the WebAssembly module, hiding the complexity of instantiation and making caches easier to build.</li>
<li>If your problem domain can be computationally intense, it might be prudent to offload jobs onto a web worker, which is easier if every function of your facade is asynchronous.</li>
<li>It will be easier for both you and your users to expose any important function as asynchronous out of the gate.</li>
</ul>
<h2>2. Assume Rust Can Trivially Do IO</h2>
Whatever you do: avoid assuming that Rust libraries (like <code>reqwest</code> or <code>rand</code>) will be able to perform IO without some work on your end. WebAssembly alone is not capable of IO, which means any function in that category will require some amount of JavaScript to work properly.
Rather than leaving that up to the Rust toolchain to figure out, save yourself the headache and inject the necessary JavaScript functions directly into the WebAssembly module by passing them through <code>wasm_bindgen</code>.
<hr>
<h2>3. Just Inline the WebAssembly Module</h2>
Obsidian plugins, for example, must be composed of exactly one JavaScript file, which means everything must be inlined. In the interest of keeping the bundle size small, it's much easier for the package developer (of <code>harper.js</code>) to set up inlining than the plugin developer.
On the other side of the spectrum, Chrome's Manifest V3 disallows WebAssembly from being loaded inline.
If you plan for your package to be consumed by a variety of applications, know that it will also be consumed by a variety of bundlers. Both bundlers and applications are pretty inconsistent with their inlining and tree-shaking behavior. To avoid problems, you should provide two versions of your package:
<ul>
<li>One where your WebAssembly module is already inlined.</li>
<li>One where it isn't.</li>
</ul>
<h1>Wrapping it Up</h1>
Harper’s problem domain is not your problem domain.
We have to integrate with a variety of unique applications, which means we must keep our system flexible.
That may not be the case for you, which may mean these footguns do not apply.
If you have any questions about any other problems the Harper project might have faced, let me know.

Four years in Rust + WebAssembly taught me these 3 lethal footguns—don’t learn them the hard way.

Four years in Rust + WebAssembly taught me these 3 lethal footguns—don’t learn them the hard way.

Footguns of the Rust Webassembly Target

why_i_talk_to_myself

<h1>Why I Talk to Myself</h1>
Each week I sit down and reflect on what I've learned. I think about which of my efforts have helped the Harper endeavor, and which have harmed it. It's not easy, but I think it's one of the best habits I've built. More accurately, it's one of the best habits Matt has encouraged me to build.
When I really think about it, I'm reminded of the original <a href="https://blog.afterthedeadline.com/">After the Deadline blog</a>, which coincidentally also had a category called "Talking to Myself". I wonder if Raphael Mudge (AtD's author) had a similar motivation.
I talk to myself to find the weaknesses in Harper's mission and focus my attention on what matters. It is an efficient way to get from <a href="https://ma.tt/2025/05/sharing-levels/">layer one to layer five</a>. It can help get other maintainers on the same page and build a body of knowledge that can be linked to from anywhere.
Not worrying about keeping information locked-down is one of the more beautiful parts of working in public. Open source code would be nothing without similarly open source knowledge. I talk to myself online so my users can understand my intentions.
In many senses, we are not unlike moths. We are drawn to the lights of distraction, hype, and procrastination. For me, setting up checkpoints to stop and reflect has been an effective deterrent from these lights. In fact, I think each minute for which I stop and think has paid itself back three times over in time savings. If I can better allocate my time and energy, I can avoid doing redundant work pursuing pointless goals.
<h2>Bonus Points</h2>
A <a href="./markov_chains_are_the_original_language_models">few</a> of my <a href="./local-first_software_is_easier_to_scale">articles</a> have become popular on sites like Hacker News and Reddit. We've gotten quite a few Harper installations from links on these articles. I would never rely on this kind of blogging as a source of advertising, but it is nice to see it help spread the word.

It's not easy, but I think it's one of the best habits I've ever built.

It's not easy, but I think it's one of the best habits I've ever built.

Elijah Potter

Why I Talk to Myself

Bonus Points

Other Stuff

Stupid Simple Spell Check

Build a Wordle Solver Using Rust

Footguns of the Rust Webassembly Target