Rust: the toolchain is 1.5 GB and the target folders are worse

Rust is generous with disk space by design. It compiles everything from source, keeps every intermediate artefact so the next build is fast, and never removes any of it. The result is predictable once you know where to look.

The three places, in the order they grow

The first row is where the space actually is, and it is invisible because it is scattered across your projects rather than collected in one folder.

Finding every target folder at once

find ~ -type d -name target -maxdepth 6 \
  -exec test -e '{}/../Cargo.toml' ';' -print0 2>/dev/null \
  | xargs -0 du -sh 2>/dev/null | sort -h | tail -20

The test for a Cargo.toml next to the folder matters, because target is a common folder name and you do not want to count a build folder from another language. Read that list by date as much as by size: a project you have not opened in a year does not need its compiled output kept.

cargo clean            # inside one project
cargo clean --release  # release artefacts only

Extra toolchains you did not mean to keep

Each toolchain is a full compiler and standard library. Installing a nightly to try one feature, or an older stable to reproduce a bug, leaves 1.5 GB behind indefinitely.

rustup toolchain list
rustup toolchain uninstall nightly-aarch64-apple-darwin

The same applies to targets added for cross compiling. rustup target list --installed shows them, and each unused one is a standard library you are storing for a platform you no longer build for.

The registry cache

~/.cargo/registry holds the compressed crates you downloaded and the extracted sources next to them. Removing registry/src is safe: cargo re-extracts from the cached archives without downloading again. Removing registry/cache costs a download the next time a crate is needed.

du -sh ~/.cargo/registry/* 2>/dev/null

What is genuinely not recoverable

Nothing on this page is. Every folder here is rebuilt by a command you already run, at the cost of one slow build. That is the difference between build output and the folders where losing something matters, which is the distinction the Xcode folders guide makes for archives, and the reason the safest order to free space puts build output near the top.