<h1>Why Rust Might Attract More Developers Than Java and JavaScript</h1>
<p>Rust is undeniably a greatly appreciated language, after all, it has placed as "#1 Most Loved Programming Language" on the StackOverflow Developer Survey for 6th year running.</p>
<p>Reading this, you are probably very aware of why so many people like it, but I will be going over those reasons anyway, at least before I reveal its secret weapon.</p>
<p><strong>It’s fast, very fast</strong>. While it may not be a great benchmark, The Computer Language Benchmarks Game, measures that it falls just a hair behind the fastest language, <strong>C</strong>.</p>
<p>That makes sense, given that Rust was meant to replace C/C++. Even better than the benchmark, it has been shown that in many situations, the Rust compiler is able to optimize code significantly better than C or C++, just because it has more information about the developers intent.</p>
<p><strong>It’s consistent</strong>. For more than pretty much any other language, Rust developers can expect that, if their code compiles, it works. When it doesn’t compile, the compiler gives better feedback and advice than any other language. It can even check if your arithmetic is wrong.</p>
<p><strong>It’s complicated</strong>, but only where it needs to be. The language itself, as well as its standard library are built very consciously, by its users. Most places where you might find you have to write tedious boilerplate, Rust makes it easy. It also gives you the freedom to write code that does exactly what you want, exactly how you want. We will get back to this later.</p>
<h2>The Problem</h2>
<p>When starting a new project what is the first thing you are going to do? It depends on what stack you are using.</p>
<p>If you want to use NodeJS, it might look something like:</p>
<pre><code class="hljs language-bash"><span class="hljs-built_in">mkdir</span> new_project
<span class="hljs-built_in">touch</span> index.js
npm install
</code></pre>
<p>That is just the bare minimum. If you want to add any dependencies, you have to go through an unreasonable number of hoops, and the standard package repository, npm, is known for being quite insecure, not to mention it being controlled by a private corporation.</p>
<p>If you want to use Java, you have to use some kind of template, otherwise it’s impossible to create a project from scratch. Even then, you have to decide between two or three package managers, and deal with it when libraries don’t support your choice.</p>
<p>If you want to use C or C++ forget it. As a beginner, you are going to be stuck figuring out how to use the local linker and compiler to get any library to work.</p>
<h2>The Rusty Solution</h2>
<p><strong>Cargo</strong> is one of the simplest, easiest to use build tools out there. It does everything you might need, and it may be why Rust may soon become a major player. 99% of the time, you can just copy and paste a given library’s string directly from <a href="https://crates.io">crates.io</a>, which is a repository owned and operated by the Rust Foundation, and you are off to the races.</p>
<p>Testing is easy too, just run <code>cargo test</code>, and you're done. It covers both unit tests, and integration tests if you need it.</p>
<p>`cargo doc`` provides a consistent, and easy way to document code. It’s also great for users, allowing developers access to a straightforward representation of what a library looks like.</p>
<p><strong>It’s extensible</strong>, some of the greatest binary crates out there exist to extend the functionality. So, in the few areas where <code>cargo</code> on its own doesn’t cut it, there are additional crates to fill the gaps.</p>
<h2>Closing</h2>
<p>At least for the moment, of all the great reasons to use Rust, <code>cargo</code> will be the most significant reason it will increase in popularity.</p>
<img src="/images/most_loved_stackoverflow_2021.png" alt="Most loved programming languages, according to the 2021 StackOverflow Developer Survey">
<p>Rust can be tough to learn, especially for people who are used to dynamic languages like JavaScript. But what Rust has beat for most languages is the build system. <code>cargo</code> alone makes Rust more approachable than C/C++, Java and many others.</p>
<p>More and more new developers will be going to Rust instead of those other languages, because it is easier to start with, easier to learn, and has a great community to request help from.</p>

A key part of Rust is far better than what JavaScript has to offer.

<p>A key part of Rust is far better than what JavaScript has to offer.</p>

Why Rust May Be More Attractive than JavaScript

<h1>Putting Harper in Your Browser</h1>
<p>When our users <a href="https://writewithharper.com">install Harper</a>, they should expect it to work anywhere they do.
Whether they're writing up a blog post in WordPress, leaving a comment on Facebook, or messaging a loved one on WhatsApp, Harper should be there.
Harper's core is extremely portable and it can run pretty much anywhere Rust can, so what's the big deal?</p>
<p>Why can't we just run Harper in the browser through a web extension?</p>
<h2>Running Locally</h2>
<p>There's a single complaint that I hear over and over again from people who use Grammarly or LanguageTool: they are both slow as molasses.
The process of writing has slowly evolved to be more complex than it needs to be.
With these tools, it writing looks like:</p>
<ol>
<li>Write a sentence.</li>
<li>Wait for the grammar checker to run (which takes as many as four seconds).</li>
<li>Fix the mistakes you made.</li>
<li>Go back to step one.</li>
</ol>
<p>The whole process reminds me of the <a href="https://thomasvogelaar.me/posts/the-copilot-pause/">copilot pause</a>.
This is part of why Harper is better than these other tools: it doesn't stop you from writing at the speed of thought.
Our most ardent users tell us this all the time: it feels great to <strong>just write</strong>, error free.</p>
<h4>How do we deliver grammar checking so quickly?</h4>
<p>Instead of hosting huge Java codebases in the cloud, we ship our software straight to the user's device.
Since there's no network request involved, we're able to put pixels on the screen faster than anyone else.
That's not to mention the privacy implications.</p>
<h4>Running Harper's engine locally in the browser presented some technical challenges.</h4>
<p>I'm quite proud that our JavaScript library can be installed as simply as <code>npm install harper.js</code>.
In order for that to work as well as it does, I needed to develop a system for:</p>
<ol>
<li>Compiling our engine to WebAssembly.</li>
<li>Shipping that engine to the browser.</li>
<li>Instantiating the WebAssembly code.</li>
<li>Build out the boilerplate necessary to make it feel native.</li>
</ol>
<p>Steps one and four were easy.
I just slapped <code>#[wasm_bindgen]</code> tags on a Rust library and put on a pot of coffee.
Steaming coffee is vital for writing tedious JavaScript.</p>
<p>Steps two and three, however, were a little more difficult.
The latest iteration of Google's extension standard, Manifest V3, places some heavy-handed rules on how executable code could be loaded.
I won't bore you with the details here.
Know that I spent many hours in JavaScript bundler hell.</p>
<h2>Running Everywhere</h2>
<p>Harper, nascent as it is, has the greatest market opportunity in the browser.
Over 3.5 <em>billion</em> people use Chrome on a weekly basis.
The plurality of knowledge workers spend most of their waking moments (as crushing as it sounds) in a web browser.
Half of the time spent at desks today is spent writing.</p>
<p>In order to address this market segment, we need a Chrome extension.
To lint text in the browser, I need a way to:</p>
<ol>
<li>Cleanly read text from input fields.</li>
<li>Locate the pixel coordinates of grammatical errors.</li>
<li>Render suggestions in popups.</li>
<li>Cleanly replace text in input fields when a suggestion is selected.</li>
</ol>
<img src="/images/harper_chrome_ext_2.png" alt="An example of Harper&#x27;s suggestion box.">
<h4>Reading and Writing Text is Hard</h4>
<p>The web may have standards, but there is nothing standard about it.
The "standard" way to input text is with a <code>&#x3C;textarea /></code> element.
Even so, most high-traffic sites implement their own text editors from scratch, using <code>&#x3C;div contenteditable="true" /></code> as a base.
Each of these cases required special care.</p>
<h3><code>&#x3C;textarea /></code></h3>
<p><code>&#x3C;textarea /></code>s are hard for one reason: it is difficult to get a good understanding of what they look like.
I can obtain their content with <code>input.value</code>, but I can't directly infer the pixel coordinates of grammatical errors inside them.</p>
<p>When the Harper Chrome Extension is offered an <code>&#x3C;input /></code> or <code>&#x3C;textarea /></code> element to analyze, here's what it does.</p>
<ol>
<li>Creates a new <code>&#x3C;div /></code>.</li>
<li>Copies all styles from the provided element onto the <code>&#x3C;div /></code>.</li>
<li>Using <code>position: absolute;</code>, it moves this <code>&#x3C;div /></code> directly on top of the provided element.</li>
<li>Copies the content of the provided element into the <code>&#x3C;div /></code>.</li>
<li>Uses the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Range">Range API</a> to turn the text indices emitted by Harper's engine into pixel coordinates on the <code>&#x3C;div /></code>.</li>
</ol>
<p>Using this mirroring strategy works, but has performance implications and additional complexity to handle scrolling within the element.</p>
<h3><code>&#x3C;div contenteditable="true" /></code></h3>
<p>Since elements in a <code>contenteditable</code> text editor (like Trix, Lexical, Gutenberg, etc.) actually exist in the DOM, I can just use the <code>Range API</code> to get pixel coordinates.
The trouble this time comes when I try to write a suggestion back into the editor.</p>
<p>Most documentation I could find suggests that you:</p>
<ol>
<li>Select the content of the element you wish to edit.
This can be done using <code>window.getSelection().addRange()</code>.</li>
<li>Call <code>document.execCommand('insertText', null, "YOUR TEXT")</code>.</li>
</ol>
<p>Much of this documentation acknowledges that <code>document.execCommand</code> is deprecated, but instructs you to use it anyway.</p>
<p>This is bad advice. <strong>Do not do this.</strong>
I spent an embarrassing amount of time trying to get it to work consistently.</p>
<p>The better way to replace text programmatically comes directly from the W3C standard:</p>
<ol>
<li>Manually edit the DOM in the fashion outlined by the suggestion chosen by the user.</li>
<li>Fire input events to instruct WYSIWYG editors to synchronize their internal state to the DOM.</li>
</ol>
<p>I'll admit that this is an oversimplification.
Much of the complexity here lays in determining which DOM nodes to edit or fire events on.</p>
<h2>Read the Source of Truth</h2>
<p>If you take one thing away from this post, it should be this: <strong>always read from the source of truth.</strong>
There is a lot of faulty information out there, especially when it comes to creating complex interactions with opaque systems.
If there is a source of truth, read it.
It may look intimidating or seem unnecessarily verbose.
It is that way for a reason.</p>

When our users install Harper, they should expect it to work anywhere they do.

<p>When our users install Harper, they should expect it to work anywhere they do.</p>

Putting Harper in your Browser

<h1>ChatGPT for the Moms</h1>
<img src="/images/guggenheim.webp" alt="Spring has sprung, and Guggenheim shows it.">
<p>My mom is a violently intelligent woman.
But she lives in the unfortunate reality of not being a software engineer or mathematician.
While she is just as excited about ChatGPT (and all the other nascent AI technology) as the rest of us, she isn't aware of the unintelligent pitfalls artificial intelligence has these days.</p>
<p>If your mom is experimenting with ChatGPT, I'd highly recommend sending this list to her.
Powerful technology is in their hands, but I've got three things they should know before relying on it.</p>
<h2>Advice for Moms</h2>
<h3>Use Web Search</h3>
<p>My mother recently learned how to make cobbler.
She adored asked ChatGPT questions about the recipe, and how she could improve it using the ingredients she had on hand.
Unfortunately, she was getting subtly wrong information from the bot, so the cobbler turned out "sub-par".
This can be solved by using ChatGPT's web search.</p>
<p>When you open up ChatGPT on a phone or on a computer, you'll be met with the familiar chat window.
If you ask it questions it will give you an answer.
Sometimes that answer will be good, sometimes not.</p>
<p>You can generally get better information if you enable the web search tool.</p>
<img src="/images/chatgpt_web_search_tool.png" alt="A screenshot of the ChatGPT web search tool.">
<p>This will allow ChatGPT to do Google searches on your behalf.
It improves the quality of information it gives you, while only adding a second or two to their response.</p>
<h3>It Is Not Your Friend</h3>
<p>When we see a chat window, our first thought is that there's a person on the other end.
Someone with emotions and lives all their own.
That is not the case here.</p>
<p>ChatGPT, while an advanced machine learning model, is not a person.
It does not replace real human connection.
It can't watch your kids when you've got an emergency.
It won't show up to the school recital.
It doesn't care about you—despite what it says.</p>
<p>There's a lot that goes into a genuine social connection, all of which are missing from ChatGPT.</p>
<h3>Use Your Brain</h3>
<p>ChatGPT is no substitute for critical thought.</p>
<p>It cannot do most things, even if it claims it can.
You are a capable human being—able to accomplish anything you put your mind to.
While ChatGPT can be a helpful assistant or brainstorming partner, don't let it steer the ship.</p>
<h2>What to Remember</h2>
<p>While ChatGPT can be a powerful tool in the right hands, it is important to remember it is just that: a tool.
It can be enhanced with the right settings, it is not real human connection, and it can't replace your brain.
Use it well and use it wisely.</p>

Advice you can give your mom (or other nontechnical person) for how to use ChatGPT wisely and effectively.

<p>Advice you can give your mom (or other nontechnical person) for how to use ChatGPT wisely and effectively.</p>

ChatGPT for the Moms

local-first_software_is_easier_to_scale

<h1>Local-First Software is Easier to Scale</h1>
<img src="/images/flatirons.webp" alt="The Flatirons">
<p>The title of this post is somewhat misleading. Local-first software rarely needs to be scaled at all.</p>
<p><a href="https://writewithharper.com">Harper</a> recently received a massive increase in both traffic and user count.
How?
By making it to the front page of Hacker News.
If you couldn't tell by the extent to which I talk about this, I'm thrilled.
This amounted to a tremendous amount of free advertising, if nothing else.</p>
<p>I've been thinking a lot about the wondrous benefits of working at the edge.
That's just one term of many that people use to describe Harper: "edge-first".
Others include "local-first" or simply "on-device".
They are all just jargon for a simple idea: We run all the relevant grammar checking code as physically close to the users as possible.
That way, we can serve up suggestions faster than anyone else.
To achieve our goal, we make sure that everything is well-optimized and lean.
Harper barely uses any CPU or memory at all.</p>
<p>What does all this mean in the context of the recent uptick in user acquisition? Imagine, for a moment, we are LanguageTool.
Our software is written in Java, with questionable attendance to the efficiency of our code.
Since our software requires a big server to run, we have a certain number of servers on standby to handle a certain amount of expected load.</p>
<p>If suddenly the number of requests we received were to double (as it did for the Chrome extension), we would be big trouble.
To avoid increasing the latency on requests (or dropping requests all together), we would need to scale up the number of running servers.
This not only takes hiring an expert in cloud architecture, but also additional funding to pay the AWS (or whatever) bill at the end of the month.</p>
<p>Because Harper runs at the edge (no server required), we don't have to worry about that.
In fact, I only noticed that our user count had spiked after I visited Hacker News the morning after.
No hiccups at all.</p>
<p>Lots of cloud providers like to brag about being able to scale with their users. I like to brag about not having to scale at all.</p>

The title of this post is somewhat misleading. Local-first software rarely needs to be scaled at all.

<p>The title of this post is somewhat misleading. Local-first software rarely needs to be scaled at all.</p>

Elijah Potter

Local-First Software is Easier to Scale

Other Stuff

Why Rust May Be More Attractive than JavaScript

Putting Harper in your Browser

ChatGPT for the Moms