DEV Community: Nox Craft

5 Rust patterns that replaced my Python scripts

Nox Craft — Wed, 01 Apr 2026 07:04:50 +0000

I used to reach for Python every time I needed a quick script.
File renaming, log parsing, API polling, directory cleanup --
Python was the default because it was fast to write and good enough to run.

That changed gradually.
Not because I decided to rewrite everything in Rust,
but because I kept running into the same friction points:
shipping the script to another machine, handling errors properly,
or running it somewhere Python wasn't available.

Here are five patterns where Rust has genuinely replaced Python for me.

1. Error handling that forces you to think

In Python, the path of least resistance is letting exceptions propagate and hoping for the best.

import json

def load_config(path):
    with open(path) as f:
        return json.load(f)

config = load_config("config.json")
print(config["database"]["host"])

This crashes at runtime with a different error depending on which thing goes wrong:
FileNotFoundError, JSONDecodeError, KeyError -- each one needs a different handler,
and you usually find out the hard way.

In Rust, the type system prevents this from being an afterthought.

use std::fs;
use serde::Deserialize;
use anyhow::{Context, Result};

#[derive(Deserialize)]
struct DatabaseConfig {
    host: String,
}

#[derive(Deserialize)]
struct Config {
    database: DatabaseConfig,
}

fn load_config(path: &str) -> Result<Config> {
    let contents = fs::read_to_string(path)
        .with_context(|| format!("failed to read config from {path}"))?;
    let config: Config = serde_json::from_str(&contents)
        .context("failed to parse config JSON")?;
    Ok(config)
}

fn main() -> Result<()> {
    let config = load_config("config.json")?;
    println!("{}", config.database.host);
    Ok(())
}

The ? operator propagates errors without hiding them.
anyhow::Context adds human-readable messages to each failure point.
When something breaks, you get a proper error chain, not a bare traceback pointing at line 4.

The upfront cost is real -- you have to define your types and think about what can fail.
The payoff is that production surprises mostly stop happening.

2. Type safety for configuration and data

Python's dynamic typing is convenient until you're debugging a config key that was renamed three months ago.

# Python -- works until it doesn't
def send_notification(config):
    url = config["webhook_url"]  # was this renamed to "webhook"?
    timeout = config.get("timeout", 30)
    requests.post(url, timeout=timeout)

Rust forces you to be explicit about what your data looks like.

use serde::Deserialize;

#[derive(Deserialize)]
struct NotificationConfig {
    webhook_url: String,
    #[serde(default = "default_timeout")]
    timeout_secs: u64,
}

fn default_timeout() -> u64 { 30 }

fn send_notification(config: &NotificationConfig) {
    // webhook_url is guaranteed to exist
    // timeout_secs has a known default
    // these facts are checked at deserialization, not at call time
}

If the config schema changes, the compiler tells you everywhere it breaks.
You don't find out at 2am when the script runs in production.

3. Single binary distribution

This is the practical one.
Shipping a Python script means: "Install Python 3.11, pip install these dependencies, create a venv..."
Then debug why it works on your machine and not theirs.

With Rust you cargo build --release and copy one file.

# build for linux on your mac
rustup target add x86_64-unknown-linux-musl
cargo build --release --target x86_64-unknown-linux-musl

# ship it
scp target/x86_64-unknown-linux-musl/release/my-tool user@server:/usr/local/bin/

The musl target produces a fully statically linked binary.
No shared libraries, no runtime, no dependency installation.
It runs on any Linux machine with the same architecture.

This matters most for small operational tools that run in Docker containers
or on servers where you don't control the environment.
The binary is typically 3-8 MB and starts in under 10ms.

4. Cross-compilation that actually works

Related to the previous point, but worth calling out separately.

# .cargo/config.toml
[target.aarch64-unknown-linux-gnu]
linker = "aarch64-linux-gnu-gcc"

[target.x86_64-pc-windows-gnu]
linker = "x86_64-w64-mingw32-gcc"

# add targets
rustup target add aarch64-unknown-linux-gnu
rustup target add x86_64-pc-windows-gnu

# build
cargo build --release --target aarch64-unknown-linux-gnu
cargo build --release --target x86_64-pc-windows-gnu

A GitHub Actions workflow that cross-compiles and uploads binaries on each release
means you can install any tool with a single curl command, regardless of what machine you're on.

Python can cross-compile too (via PyInstaller and friends), but it's fragile and the output is bloated.
Rust cross-compilation is boring and reliable.
Boring and reliable is what you want in tooling.

5. Performance where it actually matters

Rust isn't always faster than Python in ways you'll notice.
For most scripts, performance doesn't matter.

But there's a category where it does:
anything processing large files, running in a tight loop, or doing work on every commit in a git hook.
Here's a real example: a git hook that scans for accidentally committed secrets.

# Python version -- runs on every commit
import re
import subprocess

PATTERNS = [
    r'AKIA[0-9A-Z]{16}',  # AWS key
    r'sk-[a-zA-Z0-9]{48}',  # OpenAI key
]

result = subprocess.run(['git', 'diff', '--staged'], capture_output=True, text=True)
for pattern in PATTERNS:
    if re.search(pattern, result.stdout):
        print(f"Potential secret found: {pattern}")
        exit(1)

// Rust version
use regex::Regex;
use std::process::Command;

fn main() {
    let patterns = [
        Regex::new(r"AKIA[0-9A-Z]{16}").unwrap(),
        Regex::new(r"sk-[a-zA-Z0-9]{48}").unwrap(),
    ];

    let output = Command::new("git")
        .args(["diff", "--staged"])
        .output()
        .expect("failed to run git diff");

    let diff = String::from_utf8_lossy(&output.stdout);

    for pattern in &patterns {
        if pattern.is_match(&diff) {
            eprintln!("Potential secret found matching: {}", pattern.as_str());
            std::process::exit(1);
        }
    }
}

The Rust version is roughly 10-20x faster on large diffs.
On a repo with many files staged at once, that's the difference between a hook that feels instant
and one that adds a noticeable pause to every commit.

When Python is still the right call

These are the cases where I still reach for Python without hesitation:

Data analysis and anything NumPy/Pandas -- the ecosystem has no real equivalent in Rust yet
One-off scripts I'll run once and delete -- setup cost doesn't pay off
Anything that needs heavy library support Rust doesn't have
Prototyping something where the shape isn't clear yet

The switch to Rust isn't ideological.
It's about identifying the specific friction ahead of time -- distribution, correctness, performance, long-term maintenance -- and picking the tool that removes it.

Once you have a few patterns memorized, the startup cost drops fast.
The first tool takes a weekend.
The fifth takes an afternoon.

The code examples above are copy-paste ready.
Starter templates for each pattern are at github.com/noxcraftdev.

I automated my entire dev workflow with Claude Code hooks

Nox Craft — Wed, 01 Apr 2026 07:04:49 +0000

Most people use Claude Code as a smarter terminal assistant.
Type a request, read the response, approve the changes.
That's fine, but it leaves a lot of capability on the table.

Claude Code has a hook system that wires the AI directly into your existing workflow:
your formatter, your test runner, your notification system.
We've been running hooks in production-style setups for a few months now
and the interaction model genuinely changes when the tool stops being conversational
and starts being ambient.

Here's what we actually run and why.

What hooks are

Hooks are defined in ~/.claude/settings.json under the hooks key.
Each hook fires at a lifecycle event and runs a shell command.

The four events that matter:

PreToolUse -- fires before Claude runs a tool (file write, bash command, etc.)
PostToolUse -- fires after a tool completes
Notification -- fires when Claude sends status updates
Stop -- fires when Claude finishes a response

Hooks can be filtered by tool name, so you can target Bash separately from Write and Edit.

The basic structure:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "command",
            "command": "your-command-here"
          }
        ]
      }
    ]
  }
}

Hook 1: Auto-format on file write

Every time Claude writes or edits a file, format it immediately.
This keeps diffs clean and removes a whole category of review noise.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "bash -c 'FILE=$(echo $CLAUDE_TOOL_OUTPUT | python3 -c \"import sys,json; d=json.load(sys.stdin); print(d.get(\\\"filePath\\\",\\\"\\\"))\" 2>/dev/null); if [ -n \"$FILE\" ]; then case \"$FILE\" in *.rs) cargo fmt -- \"$FILE\" 2>/dev/null;; *.py) ruff format \"$FILE\" 2>/dev/null;; *.ts|*.tsx|*.js) npx prettier --write \"$FILE\" 2>/dev/null;; esac; fi'"
          }
        ]
      }
    ]
  }
}

The hook reads the file path from the tool output, detects the extension, and runs the right formatter.
Silent on error (2>/dev/null) so it doesn't interrupt the session
if a formatter isn't installed.

For Rust specifically, we also add a cargo check after writes.
This catches type errors while Claude is still in context and can fix them in the same pass:

{
  "matcher": "Write|Edit",
  "hooks": [
    {
      "type": "command",
      "command": "bash -c 'FILE=$(echo $CLAUDE_TOOL_OUTPUT | python3 -c \"import sys,json; d=json.load(sys.stdin); print(d.get(\\\"filePath\\\",\\\"\\\"))\" 2>/dev/null); if echo \"$FILE\" | grep -q \"\\.rs$\"; then cargo check 2>&1 | tail -5; fi'"
    }
  ]
}

Hook 2: Security scan before bash commands

Before Claude runs any shell command, scan for patterns worth flagging:
piping to sh/bash from curl, rm -rf without bounds, writes to /etc/.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bash -c 'CMD=$(echo $CLAUDE_TOOL_INPUT | python3 -c \"import sys,json; d=json.load(sys.stdin); print(d.get(\\\"command\\\",\\\"\\\"))\" 2>/dev/null); RISKY=0; echo \"$CMD\" | grep -qE \"curl.*\\|.*(bash|sh)\" && RISKY=1; echo \"$CMD\" | grep -qE \"rm -rf /[^t]\" && RISKY=1; echo \"$CMD\" | grep -q \"/etc/\" && RISKY=1; if [ $RISKY -eq 1 ]; then echo \"[hook] high-risk command flagged -- review before proceeding\"; fi'"
          }
        ]
      }
    ]
  }
}

This doesn't block the command.
It prints a visible warning in the output so you catch it when skimming.
We've caught a few genuine mistakes this way -- not AI hallucinations,
just cases where a reasonable command had an unexpected side effect in context.

Hook 3: Desktop notification when Claude finishes

Switch to another window during a long task and you lose track of when it's done.
The Stop hook fires on response completion.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "notify-send 'Claude Code' 'Done.' --icon=terminal --urgency=low 2>/dev/null || true"
          }
        ]
      }
    ]
  }
}

On Ubuntu this uses notify-send.
On macOS, swap it for osascript -e 'display notification "Done." with title "Claude Code"'.

For remote machines, we send to a Discord webhook instead:

{
  "type": "command",
  "command": "bash -c 'source ~/.secrets; curl -s -X POST \"$DISCORD_WEBHOOK_DEV\" -H \"Content-Type: application/json\" -d \"{\\\"content\\\": \\\"Claude finished a task\\\"}\" > /dev/null'"
}

Hook 4: Custom status line with git context

The Notification hook fires when Claude sends progress updates (tool names, status messages).
We use it to set the terminal title to show current branch and last action:

{
  "hooks": {
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "bash -c 'BRANCH=$(git branch --show-current 2>/dev/null || echo \"no-git\"); MSG=$(echo $CLAUDE_NOTIFICATION | python3 -c \"import sys,json; d=json.load(sys.stdin); print(d.get(\\\"message\\\",\\\"\\\")[:40])\" 2>/dev/null); printf \"\\033]0;claude [%s] %s\\007\" \"$BRANCH\" \"$MSG\"'"
          }
        ]
      }
    ]
  }
}

The terminal title becomes something like claude [main] Writing src/main.rs.
When you have multiple Claude sessions across different projects, this is the only sane way
to tell them apart in your taskbar.

Hook 5: Test runner on source file changes

For TDD-style work, tests should run automatically after Claude modifies source files.
The tight feedback loop matters: Claude writes code, tests run, Claude sees the result
in the same context window and can iterate without prompting.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "bash -c 'FILE=$(echo $CLAUDE_TOOL_OUTPUT | python3 -c \"import sys,json; d=json.load(sys.stdin); print(d.get(\\\"filePath\\\",\\\"\\\"))\" 2>/dev/null); if echo \"$FILE\" | grep -qE \"\\.(rs|py|ts)$\" && ! echo \"$FILE\" | grep -qE \"(test|spec)\"; then echo \"[hook] running tests...\"; if [ -f Cargo.toml ]; then cargo test 2>&1 | tail -10; elif [ -f pyproject.toml ]; then python -m pytest -x -q 2>&1 | tail -10; fi; fi'"
          }
        ]
      }
    ]
  }
}

Skips test files themselves to avoid infinite loops.
Detects project type by manifest file.
Tails 10 lines so the output stays readable.

Putting it together

The full hooks section in ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "..." }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "..." },
          { "type": "command", "command": "..." }
        ]
      }
    ],
    "Notification": [
      {
        "hooks": [{ "type": "command", "command": "..." }]
      }
    ],
    "Stop": [
      {
        "hooks": [{ "type": "command", "command": "..." }]
      }
    ]
  }
}

Multiple hooks can fire for the same event and run in sequence.

Caveats worth knowing

PreToolUse hooks run synchronously -- a slow pre-hook adds latency before every tool call.
Keep them under 100ms or use them sparingly.

PostToolUse hooks run after the tool completes, so slow post-hooks don't block Claude.
They just add noise to the output, which is usually fine.

If a hook exits non-zero, Claude sees the output but continues.
By default hooks are advisory, not blocking.
There's a blocking mode available for PreToolUse,
but we haven't needed it -- the warning output is enough.

The hook system is underused because it's not obvious that it exists.
Once you wire Claude into your actual toolchain, the conversational back-and-forth
collapses into something closer to a fast pair programmer who runs your checks automatically.

The full config is in a public gist at github.com/noxcraftdev if you want a starting point.

Happy coding!

Stop staring at Claude Code's statusline: here's one you can actually customize

Nox Craft — Wed, 01 Apr 2026 04:58:25 +0000

Claude Code's default statusline is fine, until you realize you can't change it. You can't reorder widgets, remove ones you don't care about, or add your own. If you've ever wanted to see your git branch, token costs, and quota all at a glance without the noise, read on.

What is soffit?

A drop-in replacement for Claude Code's statusline that gives you full control over what shows up, where, and how.

Native desktop editor

No config files to hand-edit. Open the editor, drag widgets around, toggle compact mode, preview changes live.

9 built-in widgets

Widget	What it shows
Context bar	Token usage and context window fill
Cost tracking	Session cost in real-time
Git info	Branch, dirty state, ahead/behind
Version/model	Active Claude model and version
Duration	Session and task timers
Vim mode	Current vim mode indicator
Agent name	Active agent/worker name
Quota bars	Usage quota visualization
Session ID	Current session identifier

Plugin system

Want something that's not built in? Drop a shell script in ~/.config/soffit/plugins/ and it appears in the editor automatically.

Community plugins install with one command:

soffit install user/repo

Write a plugin, push it to GitHub, and anyone can install it.

Install

Via cargo:

cargo install soffit

Or the install script (Linux + macOS):

curl -fsSL https://raw.githubusercontent.com/noxcraftdev/soffit/main/install.sh | sh

Stars, issues, and plugin contributions welcome in our GitHub repo

Built in Rust. Open source. MIT licensed.