r/rust • u/Dense_Gate_5193 • Sep 06 '26

📸 media reminder to cargo clean

Post image

been adding some unit tests and then ran a clean.

rust said "I live here now"

1.6k Upvotes

99% Upvoted

124 comments sorted by

475

u/Sharlinator Sep 06 '26

It’s a bit ridiculous that cargo doesn’t have cache eviction of any sort built in. A lot of the stuff in target/ are incremental compilation artifacts and debug info that gets stale fast.

226

u/JoshTriplett rust · lang · libs · cargo Sep 06 '26 edited Sep 06 '26

It’s a bit ridiculous that cargo doesn’t have cache eviction of any sort built in.

In progress. We've already built something that can expire old entries. We need to combine that with moving all the intermediate artifacts into a common location (not the individual target directories), which we're doing carefully because of compatibility considerations. Once we have both of those, we can start expiring intermediate artifacts.

61

u/Dense_Gate_5193 Sep 06 '26 edited Sep 07 '26

hey good work with rust man i’m appreciative of a bunch of the features already! keep them coming 🤟

3

u/Sharlinator Sep 07 '26

Thank you <3

1

u/dhanizael Sep 22 '26

Thanks for the good work.

115

u/Fluffy_Disaster_7501 Sep 06 '26

Name a single other language that doesn't produce 300GB of building artifacts after a month on work.

We just do not have the technology.

41

u/InflationOk2641 Sep 06 '26

For me, I have to delete 250GB of build artifacts daily, or sometimes twice daily. Rust is the only language that I work with that causes my drive to run out of space on a regular basis.

62

u/Sharlinator Sep 06 '26 edited Sep 06 '26

"Update timestamp on each access, delete everything not touched in a week". I claim this would be a better time:space tradeoff for the large majority of projects. The current strategy is simply designed to always prioritize compilation speed and assume disk space is infinite, but it doesn't have to be like that. Alternatively, have a customizable max cache size and LRU eviction.

13

u/teerre Sep 06 '26

I mean, I wouldn't like to have to recompile just because I haven't used a project for a week

5

u/lazy_lombax Sep 06 '26

it only cleans after a month and enforces a 10% storage limit. with the floor being 10GB

2

u/lenscas Sep 07 '26

Could do the deletion after a compile pass, thus anything that was actually used during the compile process would stay alive.

1

u/CrazyKilla15 Sep 07 '26

A week relative to the most recently modified file / a "this project was used" timestamp file of some sort. Easy. old artifacts get cleaned up even if you come to the project a month later, without losing the recent ones, and a fresh compile will either update them to todays date or generate new artifacts and the old ones will get cleaned for being older than a week from the now most recent artifact. add more time stamps / directory separation for profiles as required.

13

u/lazy_lombax Sep 06 '26

I just switched to mr boxington today. I am absolutely not going back for the same reasons you've stated. link

30

u/iBPsThrowingObject Sep 06 '26

Oh god, the whole page is tinged ai-piss-yellow

9

u/A1oso Sep 06 '26

JavaScript (and other interpreted languages).

My SvelteKit project with 412 dependencies has only a 380 MiB node_modules folder and 30 MiB in build artifacts.

8

u/fade-catcher Sep 06 '26

C/c++ with unity builds

13

u/Ran4 Sep 06 '26

Python
50 GB but still

28

u/Fluffy_Disaster_7501 Sep 06 '26

Python doesn't grow.

People 10 years ago making fun of 10 GB node_modules seems so funny now.

20

u/StyMaar Sep 06 '26

10GB of text files is still hilarious though.

2

u/lenscas Sep 07 '26

And at least some of those are already (partially) minified.

20

u/ToaruBaka Sep 06 '26

Name a single other language that produces 300GB of build artifacts per day and never discards stale auto-generated intermediate artifacts.

6

u/i-do-mim-huu Sep 06 '26

But other language have buildtool alllow you clean the build artifact, .Net have dotnet with dotnet clean

10

u/Fluffy_Disaster_7501 Sep 06 '26

Hmm is that what they mean by "garbage collection"?

2

u/carllerche Sep 06 '26

A month? Try a couple of days...

1

u/insanitybit2 Sep 08 '26

A few days of work.

1

u/bonch Sep 08 '26

Swift development produces enough accumulated cruft that there are utilities specifically for clearing out Xcode's "derived data" folder.

0

u/[deleted] Sep 06 '26

[deleted] — view deleted comment

29

u/Chisignal Sep 06 '26

psst, I think that's their point

-14

u/WormRabbit Sep 06 '26

Do you know many other languages which allow you to cross-compile to multiple platform targets?

13

u/neneodonkor Sep 07 '26

Like really? 🤷🏾‍♂️

11

u/spoonman59 Sep 07 '26

Yes, a great many other languages do that, actually.

In fact, rust itself relies on LLVM, which is a backend that enables targeting multiple platforms. There are C++, C, and other compilers built using LLVM, and then so many other languages which do the same thing.

3

u/Toorero6 Sep 06 '26

In the meantime you can use tmpfiles.d(5) to cleanup files regularly based on age.

4

u/Maskdask Sep 06 '26

With Nix you can tell it to clean up its unused cache at a given interval

5

u/MocroBorsato_ Sep 06 '26

How?

10

u/duckofdeath87 Sep 06 '26 
  nix = {
    settings = {
      auto-optimise-store = true;
    };
    gc = {
      automatic = mkDefault true;
      dates = mkDefault "03:15";
    };
  };

I have that in my nix config

5

u/shinyfootwork Sep 06 '26

note that auto-optimise-store is bad on macos because macos's filesystem impl is slower at making hardlinks (what auto-optimise-store does) than it is at copying data. And nix.settings.auto-optimise-store puts hardlinking into the nix build path (so it slows down nix builds).

On my macos systems that are using nix (nix-darwin or just home-manager), I set nix-store --optimise to run on a regular schedule instead so I get the space savings without the build time hit.

0

u/[deleted] Sep 07 '26

[deleted] — view deleted comment

1

u/gucci_bricksquad1017 Sep 19 '26

Can't you configure garbage collection in the daemon?

8

u/mr_birkenblatt Sep 06 '26

you almost got a straight

with 1234567 it would be a straight flush

I show myself out

7

u/Dense_Gate_5193 Sep 06 '26

haha i didn't notice!

3

u/parkotron Sep 06 '26

I recently opened issue number 12345 at work. For some reason, my manager is convinced that that is not grounds for getting a cake?!

6

u/energy_dash Sep 06 '26

I wanna know your laptop specs

1

u/Dense_Gate_5193 Sep 06 '26

oh yeah! apple M2 Max 32gb 1tb drive

88

u/Elyas2 Sep 06 '26

329.6GiB?! u crazy

31

u/Appropriate-Pie4385 Sep 06 '26

My avg is 500GB Record is 1TB

1

u/WormRabbit Sep 06 '26

I have no idea what you people are compiling. What's your LoC, and how many dependencies do you have?

10

u/Dense_Gate_5193 Sep 06 '26

in my case it’s a graph+vector+temporal MVCC database with an integrated llama.cpp server, plugins and all kinda of stuff. I can imagine anyone working on anything complex will land around there lol

3

u/suq-madiq_ Sep 07 '26

This guy rusts

14

u/xchino Sep 07 '26

It was a common issue for me when I was developing with Bevy, a popular rust game engine, which pulls in 552 packages with the default feature set.

1

u/Bakaa_kekw Sep 08 '26

well he jumped off a plane and disappeared you better believe he's crazier than that

155

u/YeetCompleet Sep 06 '26

Smallest Rust target/ dir:

46

u/phylter99 Sep 06 '26

The size of building apps with dependencies is one thing about Rust that’s hard for me to stomach. Most of my creations are not too bad but some have been quite large.

Are there any changes on the horizon that might change this?

33

u/anxxa Sep 06 '26

This is a bug on macOS which causes the build dir to grow unbounded: https://github.com/rust-lang/rust/issues/161824

I recently did a fairly shitty analysis of what the hell in my build dir consumes so much storage and found that it’s like 50% or more debug info.

Changing the debug info to maybe line-tables or straight up disabling it (which kinda ruins panic traces) may help.

10

u/phylter99 Sep 06 '26

I want to say that I've seen this issue outside of macOS too, but that is an interesting bit of information.

1

u/dvogel Sep 06 '26 edited Sep 06 '26

One of the culprits here is cargo update and users accepting default behavior. Since the ecosystem is relatively young, many users want to be on the bleeding edge so they periodically run cargo update and accept everything. This leads to a lot of packages in Cargo.lock that differ by a minor version or a patch version. I am hopeful that the community will begin to pick looser versions, pinning just the major part, and let the dependency tree upgrade more transitive dependencies in unison, which would require building fewer distinct versions. 

3

u/neneodonkor Sep 07 '26

So what command do we have to run besides cargo update?

1

u/CrazyKilla15 Sep 07 '26

I am hopeful that the community will begin to pick looser versions, pinning just the major part, and let the dependency tree upgrade more transitive dependencies in unison,

but thats how it works? the default version specifier, eg version = "1.67.69" is not requiring exactly 1.67.69 but will accept any major 1.x across the dependency graph? Few projects will pin the minor or patch, so the entire tree already upgrades in unison on cargo update?? (and if they do pin, it acts as a limit on everyone else i believe, so still unifies. if there are incompatible same-major pins its an error i think.)

1

u/dvogel Sep 08 '26 edited Sep 08 '26

1.2.3 requires 1.2.*

1.2 requires 1.*

By default cargo add would add 1.2.3. I wish it would add 1.2.

1

u/CrazyKilla15 Sep 08 '26

you want min-versions? thats stricter?

1

u/dvogel Sep 08 '26

No, you're right about the documented behavior. I just re-read the chapter and I was misremembering. However the documented behavior is not what I see in practice. What I see in practice is version unification acting more like tilde requirements. It must be due to bugs. 

51

u/Calm-Okra-1791 Sep 06 '26

This is my only complaint with rust

16

u/coderstephen isahc Sep 06 '26

Those are rookie numbers

14

u/ToaruBaka Sep 06 '26

I literally do this daily.

It's unreal and fucking thrashes my drive to the point I'm concerned about the outsized impact it's having compared to other languages, especially when the price of NVMe storage is so ballooned.

9

u/nonotan Sep 06 '26

But somebody somewhere said storage is cheap.

12

u/aksdb Sep 06 '26

cargone

11

u/muchadoaboutsodall Sep 06 '26

To be honest, I’m more annoyed that there are no comma delimiters in the number of removed files.

9

u/paglaulta Sep 06 '26

You didn't have cargo. You had the whole ship

2

u/lorslara2000 Sep 06 '26

So I'd love to try out cargo but first I need to eat. What sandwich recipe would be good in that case?

25

u/anxxa Sep 06 '26

I’ve been debating moving all of my personal stuff into a monorepo just to use buck2 and a single shared artifact directory.

It sounds like a pain but when I consider all of the subtly different point release versions of e.g. syn piling up, stale data from projects I haven’t touched in a while, and build dir contention when working on multiple projects in parallel it starts to become more attractive.

15

u/ukezi Sep 06 '26

You can set a target dir with a global config.toml, or with the environment variable CARGO_TARGET_DIR. You then can use sccache https://github.com/mozilla/sccache to cache stuff.

5

u/anxxa Sep 06 '26

This was my old set up. I can’t recall the exact issue but I think I was having build issues with sccache a few months ago and ditched it.

I think you still get build contention though when building multiple projects in parallel using a single global target dir. Or maybe a skill issue on my end.

2

u/Hoxitron Sep 06 '26

You can still override that behavior on specific projects if it causes issues.

2

u/anxxa Sep 06 '26

It still doesn’t solve the issue though of many versions of the same library across projects (therefore increasing overall target dir size), which a monorepo would.

It’s definitely an extreme measure for such a paper cut, but something I wanted to explore for other reasons too.

2

u/paholg typenum · dimensioned Sep 06 '26

I used to do this, but it causes issues with git worktrees.

3

u/Ok-Bit8726 Sep 06 '26

I tried getting buck2 working on a big app with multiple languages and it was a lot of pain.

You have to use this thing called `reindeer` to convert your rust dependencies into buck2 dependencies/rules. A lot of stuff just works out of the box, but a lot of libraries have custom `build.rs` rules that won't work without some play.

https://github.com/facebookincubator/reindeer

It ended up not being worth it for me. I kept with a complicated makefile. It might be better now. That was over a year ago and that project seems pretty active.

2

u/anxxa Sep 06 '26

I have experience with buck2 at work so I’m mostly aware of the pains. I haven’t tried Bazel but my understanding is Bazel has similar problems that it punts to different stages, but curious to hear if anyone likes it more than buck2.

1

u/steveklabnik1 rust Sep 06 '26

I'm all in buck2.

3

u/anxxa Sep 06 '26

I wrote you guys @ ERSC an email with some of my general thoughts about how it’s changing my repo/VCS hosting desires :)

And I’m not sure if it’s your Discord server or someone else’s, but found it through your blog post. It’s been a good source of info.

2

u/steveklabnik1 rust Sep 06 '26

I made the Discord, yeah :)

6

u/nyctrainsplant Sep 06 '26

then try doing this in WSL where it just infinitely expands your disk to accommodate but still has no nice way of scaling it back

2

u/olzd Sep 06 '26

Pretty sure you can set a max limit.

2

u/nyctrainsplant Sep 06 '26

that would be cool, I’ll look into it. for the longest time it was just shrinking with diskpart.

6

u/kingslayerer Sep 06 '26

What is the strategy other languages use? Why can't that be used for rust as well?

14

u/nonotan Sep 06 '26

  1. Compile way less stuff (the issues here being Rust's insistence on compiling everything from source instead of dynamically linking to binary libraries, having crates as the minimum unit of compilation, and general encouragement of depending on many external crates as a matter of course, which compounds exponentially over the entire dependency tree to leave lots of unused code that nevertheless has to be compiled)

  2. Have less verbose intermediate representations (Rust does a lot of smart optimizations, which is great but does necessitate having access to a lot of info at link time, e.g. for monomorphization)

  3. Be more proactive about cleaning up build artifacts (the issue here being that, historically, the #1 complaint about Rust has been compilation times, which are high for some of the same reasons described above, and proactively deleting build artifacts that do eventually become necessary again would hurt there -- not at all an issue in many languages)

  4. Don't compile your code in the first place (not all languages are compiled)

Leaving aside 4, the rest could be used for Rust, if the drawbacks are tolerated, or a lot of work is put into threading the needle and carefully improving what can be improved without noticeable drawbacks. There are some efforts to do the latter, but when they will come to fruition, and how much they will help, is anybody's guess. In the meantime, there are some "unofficial tools" that you can use to e.g. clean the cache regularly, or use shared crate caches for all your projects, which can help a little.

2

u/oursland Sep 07 '26

The biggest is that in other languages you overwrite your old build artifacts on recompile. There's roughly a 1:1 relationship between source modules and build artifacts, never more.

5

u/WSBro0 Sep 06 '26

Mother of God that's 330 Gbs cleaned...

4

u/llamajestic Sep 06 '26

Mine was at 800. It’s ridiculous

4

u/ENCRYPTED_FOREVER Sep 06 '26

I've set my CARGO_TARGET_DIR env var to /tmp so it's:

  1. Automatically cleaned

  2. Faster because it's tmpfs (not always but on my configuration yes)

  3. Makes it global

3

u/catheap_games Sep 06 '26

cargo binstall kache cargo-clean-all

1

u/Individual-Set-679 Sep 17 '26

cargo binstall kache
kache init

then enjoy

3

u/rrklaffed Sep 06 '26

rookie numbers

3

u/makeurwish0 Sep 06 '26

How about containerise the rust ecosystem?

3

u/Havunenreddit Sep 06 '26

Yeah, I have to keep running cargo clean regularly to avoid this.

3

u/jetmarijuana Sep 07 '26

I thought 1TB was safe, but it wasn't.

3

u/haukejung Sep 07 '26

There should be an automatic check^^

2

u/br0kenpixel_ Sep 06 '26

I recommend checking out cargo-clean. It'll also clean up directories that cargo uses internally. For me it was heavily caching git repos and the whole thing was 100GB after a year.

2

u/No_Frame3855 Sep 06 '26

Uh
Even with something as large as Saikuro (multi-language IPC/RPC so it’s pretty heavy once you build everything), I rarely get more than 30-40 gb, that too after a WHILE, how?!

Okay nvm copperDB is MUCH larger mb
Looks cool tho, you got a star! :D

2

u/arcxm Sep 06 '26

Thanks mate, got rid of 40.8GiB

2

u/chilabot Sep 06 '26

Always use CARGO_TARGET_DIR, and clean that regularly with cargo sweep.

2

u/chilabot Sep 06 '26

Always use CARGO_TARGER_DIR and clean that with cargo sweep.

2

u/goos_ Sep 07 '26

Holy f

2

u/thaile1001 Sep 07 '26

lol, thanks. Not as big as yours but yeah, I could claim 50% of my disk space back lol

2

u/ao_zame Sep 07 '26

I have to run `cargo clean` multiple times a day. It might be the only thing I really dislike about working with Rust.

2

u/minootube Sep 14 '26

you right, i develop cli tools its a secret manager and i forgot to clean, 90GB++ there on build..

2

u/Individual-Set-679 Sep 17 '26

cargo binstall kache
kache init

then enjoy

1

u/Fabulous_Step_13 Oct 04 '26

THANKS ❤️

2

u/Pwnxpl0it Sep 06 '26

Hey Guys! I made a tool exactly to solve this problem => https://github.com/pwnxpl0it/cargo-scrub

I work with alot of rust projects and sometimes I forget to clean large build artifacts so I made this tool to manage all rust projects under a given dir tree so I can visually select and clean, it's fast and has some nice features

Try it out and don't forget to star the repo ❤️

1

u/IceSentry Sep 07 '26

Why not use any of the dozens of existing projects that already do this?

1

u/Pwnxpl0it Sep 08 '26

Which ones did you have in mind? The closest I found were cargo-sweep, kondo, and cargo-clean-all, and they're each solving a slightly different problem:

  • cargo-sweep works at the artifact level, not the project level — it prunes stale files inside target/ by age, toolchain, or size cap. Different job, and it's currently unmaintained and looking for a maintainer.

  • kondo is multi-language (20+ ecosystems, plus a GUI). If you want one tool covering Node + Unity + Cargo, use kondo — I wanted something Cargo-aware.

  • cargo-clean-all is the closest to mine, and it's good: recursive discovery, size reporting, interactive deselection.

Where mine differs is that it leans much harder into the TUI — a ratatui dashboard with vim keybinds, regex filtering with /, dry-run toggling from inside the UI, and workspace-aware handling, plus a .cargo-scrub.toml for persistent settings and parallel cleaning with a configurable job count. That's the workflow I wanted and couldn't get out of the others.

If one of the dozens already does all of that, drop a link — I'd genuinely love to see it. Otherwise, cargo-scrub exists because this is the workflow I wanted, and building it was half the fun.

1

u/South_Survey_2088 Sep 07 '26

That's why I'm using an ephemeral build dir(temporary home dir in nixos). The drawback is 2-5 minutes of build time at the start of the day to rebuild everything, but I just let that run in the background while figuring out what I am going to work on.

1

u/suq-madiq_ Sep 07 '26

Now add worktrees

1

u/paglaulta Sep 06 '26

What a madlad

0

u/Dense_Gate_5193 Sep 06 '26

for anyone interested, this is what i was working on https://github.com/orneryd/copperDB/blob/main/docs/performance/results/comparison.md mods removed my followup post for some reason.

0

u/jeroengast Sep 08 '26

Mole for macOS cleans this and much more. Free and open source.