Building a better tool is not enough

Adopting a new tool involves pain. The devil you know tempts. Think of how much time you've spent integrating the old tool. You know all its quirks! Once you account for your own time, is the new tool that much better?

These arguments can justify standing pat on their own. Another argument lurks: tooling sprawl is the enemy. Every new tool has to work well with every other tool in the stack. The chances of that go down with every tool we add.

Uno reverse to inertia

Drop-in replacements tackle all these difficulties at once. You're telling me I can keep my pre-commit hook workflow, but with ~13x faster checks? I can replace my rickety stack of seven Python package management tools with one tool that's 100x faster?

It's no coincidence prek and uv achieved widespread, rapid adoption. Both of these projects could have just shouted “we're so much faster, use us!” Instead they went out of their way to slot into how people already worked. The speed jump hooks new potential users, but the drop-in compatibility helps them take the leap.

You don't have to rewrite in Rust

Both of those examples are tiny, dependency free, lightning fast, and written in Rust.

But Rust isn't necessary to achieve the other elements. The famously dependency free, tiny DuckDB binary is written in C++. You can drop in replace any data wrangling workflow across double digit programming languages + harness hilarious speedups.

I like Rust, and we can take many routes to “small, dependency-free binary that does an important task faster.” Even if we're not shooting for “8,700x faster!!” we can still learn from the drop-in replacement ethos. What small change it what you're building would make it more compatible with how people already work?

A data thing I liked

Datatype, a font that turns text into charts

A not-data thing I liked

The American EV has been crushed. Will it take the U.S. auto industry with it?