indexable-inc

My Rust target/ said 325 GB. My disk said 1.65 GB free. --- title: My Rust target/ said 325 GB. My disk said 1.65 GB free. published: true tags: rust, devops, ai, productivity cover_image: media.eksis.io --- so last week my Mac said the disk was full. like, actually full. 1.65 GB left out of 494 GB. !macOS Disk Utility showing 471.49 GB used and 1.65 GB free on a 494.38 GB disk I ran du on my Rust projects and target/debug came back at 325 GB. ok. found it. I posted the screenshot on Threads, three lines, asked how everyone else deals with this. got 140 comments lol. so I tried the suggestions. some context. I'm building a Rust CLI called Contexere (used to be OMNI), and I run a few AI coding agents on it at the same time, each in its own git worktree. every worktree builds its own copy of every dependency. debug, test, release, each with their own copies too. that's how one folder gets huge without you doing anything weird. what people told me - cargo clean more often. one guy runs it from a post-merge git hook, so every pull on main starts clean. smart. - symlink target/ to an external SSD, or a NAS - buy a bigger disk ("512 GB is the minimum for a Mac now", more than one person said this haha) - kache + blaze combo - stop building on the laptop, code on a remote server the two tools I could actually measure, so I started there. kache kache sits in front of rustc as RUSTC_WRAPPER, hashes every compile input and keeps the output in a shared store. so a second checkout of the same project can reuse what the first one built. I tried it on two worktrees of my repo, cargo build --locked, debug. disk measured with df free space before/after, because on APFS du lies (remember this, it comes back later). one run each, so take it as rough. !bar chart: first worktree 93 s plain vs 138 s with kache, second worktree 100 s plain vs 42 s with kache | | plain cargo | with kache | |---|---|---| | first worktree | 93 s, 1169 MiB | 138 s, 1211 MiB | | second worktree | 100 s, +1598 MiB | 42 s, +538 MiB | | both | 2767 MiB | 1749 MiB | second worktree: 230 of 232 crates came from the cache, 100 s down to 42 s. nice. but the first build was 48% slower, and the store eats disk too (default budget is 5% of the volume). it pays off when you have lots of checkouts of the same project. I only had one extra worktree at the time, so not worth it yet. uninstalled, will look again when I'm at 3+. blaze didn't even install this one, its own docs answered it. blaze is about fast incremental rebuilds and it's impressive at that. but no clean command, no GC, no size cap. on macOS arm64 their benchmark shows ~1.5x the disk of cargo (598 MB vs 416 MB on ripgrep), and the daemon uses 2.6 to 2.9 GB RAM on small projects. my Mac has 8 GB RAM and a full disk. so no. both tools make builds faster. my problem was never speed. it was disk. what I ended up doing one comment just said "time to code on a remote server". I took that literally. !diagram: the Mac writes code, commits, pushes and orchestrates over ssh, target/ is 0 B; git archive HEAD piped over ssh sends code to a cloud VM that runs cargo build, test, clippy, fmt, make ci, dev servers and screenshots; only results come back my Mac now does 3 things: write code, commit + push, and tell a cloud VM what to run over ssh. everything else runs on the VM. builds, tests, lint, the full CI gate, dev servers, even browser screenshots. git archive HEAD | ssh myvm 'tar -x -C ~/project' ssh myvm 'cd ~/project && make ci' shipping from a commit with git archive means .env, local data and gitignored stuff never leave the laptop. only results come back. full gate (fmt, clippy, tests, security check, binary smoke test) runs green there in ~4 min cold. I still cargo clean at the end of a session, never in the middle, otherwise every build after it pays the full compile again. ok but about that 325 GB this is the part I got wrong. if target/ was really 325 GB, cleaning it would give me 300+ GB back. it never did. !bar chart of free disk space: 1.65 GB on Oct 28, 34 GB a few days later before cleanup, 139 GB after deleting node_modules, a VM bundle and old apps, all far below a dashed line at 325 GB labelled du said target/debug = 325 GB a few days later, before a big cleanup, I had 34 GB free. then I deleted other junk (48.5 GB of old node_modules, an 11 GB VM bundle from a desktop app, some apps I don't use anymore) and got to 139 GB. nowhere near 325. on APFS, du can count clones and hardlinks more than once, and a cargo target dir is full of hardlinks. so the real size was way smaller than what du told me. if you want to know what a cleanup actually frees, compare df before and after. worth it? to be fair, most of the room came back from that big cleanup, not from moving builds. what the VM changed is target/ on my Mac is 0 B now and stays there, and df shows 136 GiB free. building remotely adds a few seconds of ssh + copy, and offline I can't run the full gate. fine for me. the laptop is for writing code now, and a VM is cheaper than a bigger SSD. one Rust project and a big disk? cargo clean in a git hook is probably enough. lots of worktrees of the same repo? try kache. agents building in parallel on an 8 GB laptop like me? move the builds somewhere else. the project behind all this the repo that kept filling my disk is Contexere, formerly OMNI. the one place for the skills, keys and memory of every agent you use. written in Rust. right now it ships the context layer. when an agent runs a noisy cargo test, it keeps the result and the failures and drops the progress noise. when the agent reads a file it already read, it gets a one-line handle instead of the whole file again. tokens and passwords in the output it rewrites get redacted. nothing is deleted, one command brings back whatever it trimmed. skills, keys and shared memory across agents are next. brew install fajarhide/tap/contexere && contexere init still early. if you run agents all day too, try it and tell me what breaks hehe how big is your target/ right now? 😅

Blaze: Incremental Rust builds up to 92x faster than cargo/rustc

Build headlines said 92x faster. I measured my own crate first. A few weeks ago the Rust corner of my feed lit up: a new toolchain promising dramatically faster builds, one benchmark, one headline number. I have seen this movie before: a number from somebody else's crate, somebody else's machine, and then a week of arguing about whether it applies to mine. I did not want to argue about toolchains. I wanted a ruler: something that tells me, on my crate and my machine, where the seconds actually go (per crate, per build script, per link step), then tells me which fix is cheapest, and lets me verify the delta after I apply it. So I built cargoscope. It measures. It recommends. It verifies. It never touches your toolchain. The three commands cargo cargoscope measure [--json out.json] shells out to cargo build --timings twice. The first build is timed; the second is a no-change rebuild. That second run is the trick: cargo omits fresh-skipped units from the timing report, so a build-script-run unit that still shows real duration in the no-change rebuild was genuinely executed again with no source changes. Its freshness is broken: typically a script that rewrites its own rerun-if-changed inputs. That is measured, not guessed from the script source. The report shows wall time, top crates by compile time, build scripts that re-run on every build, and the codegen+link share of the final binary. On stable, the report is honest about what it cannot separate: "link step not separable on stable — the bin unit's duration covers codegen+link together." cargo cargoscope recommend ranks fixes cheapest-first with exact config snippets: cargo check for the edit loop, fixing re-running build scripts, mold/lld linker, sccache, cranelift (gated behind --nightly-ok). It changes nothing. The snippets are yours to review and apply. cargo cargoscope compare before.json after.json prints the measured delta and a verdict line. Only measured numbers; nothing is promised. A real demo, honest numbers The animated demo below is a real terminal recording on the repo's small fixture crate (verbatim transcript also in the repo). Watch the loop: measure flags a build script with RE-RUNS ON EVERY BUILD, recommend ranks the rerun-if-changed fix, I apply it, measure again, compare: !cargoscope demo (real terminal recording): measure flags a re-running build script, recommend ranks the fix, compare verifies -6.6% wall: 0.7s -> 0.7s (-6.6%) units: 5 -> 4 verdict: -6.6% wall time faster (0.7s -> 0.7s) Small crate, small numbers, no hype. The re-run flag is gone; the per-crate deltas are printed, wins and losses. That is the whole point: the tool's job is to make the second measurement possible, not to impress you with the first. The bug the nightly CI caught To separate the link step, cargoscope parses nightly -Ztime stderr. While dogfooding on a real nightly toolchain I found that rustc 1.101-nightly removed -Ztime entirely (unknown unstable option). The old code set RUSTFLAGS=-Ztime whenever it detected nightly, and cargo forwards RUSTFLAGS into its own internal rustc probe, so measure broke completely on new nightlies (cargo exit 101). The fix: probe first (rustc -Ztime --print=sysroot; --version short-circuits before -Z validation, so it cannot be the probe), set the flag only when the probe passes, and fall back gracefully otherwise. A nightly CI job now runs measure on a real nightly toolchain every night and asserts the graceful fallback. Finding your tool broken on a toolchain you claimed to support is the best possible use of a nightly job. Where the rivals beat us Honesty section, as always with my tools: - cargo-blaze wins if in-place recompilation fits your workflow: it actually makes rebuilds faster instead of measuring them. It is a young, invasive bet (replaces the compiler driver). cargoscope complements it: it can measure blaze's own delta. - cargo build --timings wins on zero install. The raw HTML timeline has everything cargoscope parses. cargoscope adds ranking, re-run detection, and before/after verification on top. - cargo-bloat answers a different question (binary size, not build time). Honest limits - It does not speed up your builds. It measures. If you want the build itself to go faster without measuring first, this is the wrong tool. - Timing numbers are your machine's, your crate's, your profile's. A −6.6% here is not a claim about any other setup. - Link-step timing needs a nightly toolchain whose rustc still accepts -Ztime (removed by 1.101-nightly; support is probed, never assumed). - cargo --timings output format is not a stable API. The parser is defensive, records the tested cargo version, and fails loudly instead of guessing. Try it The npm package is not published yet, so install from source for now: git clone https://github.com/techdevfun/cargoscope.git cd cargoscope && npm install && npm run build # then, inside any Rust crate: npx cargo-cargoscope measure Requires Node 20+ and a Rust toolchain (stable is fine). Zero runtime dependencies, MIT licensed. Repo: techdevfun/cargoscope. Issues and PRs welcome; please include your measure output (redacted paths are fine) when reporting wrong numbers. Also listed in the TECHDEV catalog.

blaze: rebuild Rust in milliseconds, 10 to 24x faster than cargo build #Shorts For your AI agent: gitnova.dev (what it is, why it's rising, how to try it) blaze by indexable-inc rebuilds Rust in milliseconds: the same commands as cargo, with blaze in front (blaze run, blaze test, blaze build). It runs beside cargo and keeps your project compiled in memory; after an edit it compiles only the functions you changed and writes them into the program cargo already built. Per the README, edits rebuild 10x faster on macOS arm64, 24x on Linux aarch64 and 11x on Linux x86-64 than with cargo build, on average over real projects. Example from its table (Linux x86-64, edit one function, then build): bun, 1.25M lines of Rust, 9.11 s with cargo build vs 451 ms with blaze build. +540 GitHub stars in 24 hours (measured by GitNova, Oct 28, 2026). How to try it: curl -fsSL ix.dev | sh (macOS on Apple silicon and Linux; per the README, Windows x86-64 also builds through blaze, tested by hand rather than in CI, with no installer yet), then in any Rust project run blaze build. Good to know, per the README: it trades memory for speed (a few GB for a small project), builds with its own nightly Rust toolchain, and is young, so keep cargo check or your CI as the final word. MIT or Apache-2.0. Repo: indexable-inc/blaze Full breakdown: gitnova.dev More tremors: gitnova.dev Star growth is a signal of interest, not a quality rating. Narration is an AI voice; the animation is drawn in code. #Shorts #GitHub #Rust

blaze: incremental compilation for Rust that’s 10x faster than rustc and also adds hot reloading it’s fast because it recompiles only the functions that changed, thus avoiding a full linker process, and also allowing the live program to be patched indexable-inc/blaze

indexable-inc/blaze: Incremental rust builds up to 92x faster than cargo/rustc indexable-inc/blaze

> The borrow checker is new: 0.1.0 has none, so an edit with a borrow error builds and runs; the one on main finds about two thirds of rustc's borrow errors. github.com/indexable-inc/blaze/blob/main/docs/usa… Hey what could go wrong? You didn't really need 33% of your borrow-checking anyways. Only one contributor with more than four commits. Initial commit was 7 days ago. I guess now we have a "vibechecker"!

Incremental rust builds up to 92x faster than cargo/rustc #HackerNews indexable-inc/blaze

Incremental rust builds up to 92x faster than cargo/rustc indexable-inc/blaze (news.ycombinator.com)

增量编译速度比 cargo, rustc 快 92x ☄️ 这就有点厉害了 indexable-inc/blaze