Developer Tools
Everyday developer tools, reimagined in Rust. Faster testing, faster package management, and infrastructure built for the AI-native development workflow.
Background task queue that eliminates the need for Redis or RabbitMQ. Centralized coordination with distributed subworkers, priority queues, and a built-in web dashboard.
- Priority queues (critical/high/normal/low)
- Auto worker discovery
- Task result caching
- FastAPI integration
- OpenTelemetry support
$ pip install fastworker10-100x faster package management with FTS5 full-text search. Drop-in replacement for the Homebrew CLI.
- Drop-in Homebrew replacement
- Full-text package search
- Parallel operations
$ cargo install stoutRust-powered test runner with full Jest compatibility. 100x faster warm runs while keeping the same API and config.
- Full Jest compatibility
- Parallel test execution
- Snapshot testing support
$ cargo install rjestAccelerated pytest execution without configuration changes. Drop in and run faster.
- pytest compatible
- No config changes
- Prebuilt wheels
$ pip install rpytestIssue tracking that lives inside your repository, designed for AI agent workflows. No external services required.
- Append-only event log
- Git-native storage
- AI agent friendly API
$ cargo install griteWhat these tools are actually optimising
Almost every tool on this page attacks the same overlooked cost: the fixed price you pay before any useful work starts. A test runner re-parses and re-transforms source it transformed five minutes ago. A Python process re-imports a dependency tree on every invocation. A package manager parses a Ruby DSL to answer a question a database index could answer. None of that is the work you asked for, and all of it is paid again on the next run.
The shared technique is to keep something warm across invocations — a transform cache, a resident interpreter, a pre-computed index — so the second run is not charged for the first. That is why the headline numbers on this page are about warm runs. Cold runs improve much less, and saying otherwise would misrepresent where the win comes from.
Where the minutes go in a normal day
| Loop | Fixed cost paid every time | Tool that removes it |
|---|---|---|
| JavaScript unit tests on save | SWC transforms and worker startup | rjest |
| Python unit tests on save | Interpreter startup, imports, collection | rpytest |
| Background jobs in a small service | Running and operating a broker | fastworker |
| Installing a toolchain on a new machine | Ruby startup and formula parsing | stout |
| Filing and tracking work an agent did | A round trip to a hosted tracker | grite |
How to trial one without committing
Every tool here reads the configuration you already have, which makes the evaluation cheap and, more importantly, makes the rollback cheap. A reasonable trial is one developer, one week, on the loop that annoys them most: install it, run the existing suite, compare wall clock on a warm second run, and uninstall if it does not earn its place. No config migration, no lock-in step, nothing to undo in CI.
The reasoning behind that constraint — and where we deliberately break it — is written up in drop-in compatibility as a design principle. The detailed head-to-heads are at rjest vs Jest, rpytest vs pytest and stout vs Homebrew.
Limitations worth knowing before you install
A resident daemon is a process on your machine. It uses memory between runs, it has to be restarted when it gets into a bad state, and on a constrained CI box the trade may not be worth it — CI runs are usually cold, which is the case these tools help least. Their value is concentrated in the local edit-test loop.
Compatibility is also a moving target rather than a fixed property. Each project tracks a specific upstream version range, and a plugin that reaches into upstream internals is the most likely thing to behave differently. Check your plugin set against the current release notes rather than assuming parity.
Frequently asked questions
Do I have to change my test files?
No. rjest reads your existing jest config and rpytest runs your existing fixtures, plugins and conftest files unchanged. If a change to test code were required, the tool would have failed its own design brief.
Is fastworker a good fit at very large scale?
It is aimed at services in the moderate range, where running and paying for a broker is a real share of the operating cost. At very high throughput a dedicated broker and its ecosystem of tooling is still the safer choice, and the Celery comparison says so explicitly.
Why is grite in a list of developer tools?
Because issue tracking is part of the loop once agents are writing code. grite keeps the tracker in the repository as an append-only log, so an agent can file and close work without a network call and without a credential for a hosted service.
Are these safe to put in CI?
They are, but measure before you do. The speedups documented here come from warm state, and a fresh CI container has none. Adopt locally first and treat CI as a separate decision with its own numbers.