A one-project switch is safer than replacing /usr/bin/ld
Clang and GCC 12.1 or newer can select mold with -fuse-ld=mold. That single flag is the sensible way to evaluate it: rebuild one real project, run that project's tests, inspect the resulting binaries, and keep the old linker available. Rust needs a small .cargo/config.toml entry, usually with Clang as the linker driver. Older GCC uses a -B search path because its -fuse-ld handling does not recognize mold by name.
The broader system switch asks a harder question. An application build may use ordinary ELF features while a kernel module, firmware image, or installer relies on a detailed linker script. Open issue 1513 describes VirtualBox installation failing after mold was made Ubuntu's default linker. That report does not prove every failure has the same cause. It does show why a successful 36-test source run cannot certify every program installed on your machine.
What happened when we ran it
Our sandbox installed 79 packages in 40 seconds, then built commit 54b68f6 in 347 seconds. Cargo test finished in 116 seconds with 36 passed and 0 failed. We used a fresh unprivileged container with 3 CPUs and 12 GB of RAM. That is a clean result: the checked-out source installed, compiled, and passed every test the harness ran.
The repository itself held 738 files, about 63,238 lines of source, and occupied 2.4 MB before the install. Five CI workflow files and a tests directory were present; a Dockerfile was not. That layout fits a system executable that users normally obtain as a distro package or release binary. If you compile it yourself, the README calls for stable Rust, Git, and either GCC or Clang. No account, token, database, or network service is part of normal use.
The Rust code we tested is ahead of the v2.42.1 release
commit 54b68f6, dated September 19, 2026, belongs to the Rust implementation on the main branch. The latest published release is v2.42.1 from September 11, and its notes describe that version as likely the final C++ release unless another patch is needed. They say the Rust rewrite is intended for mold 3.0. A source checkout and a release download therefore give you different implementations today.
That distinction matters more than the language preference. Our 36 passing tests support the exact Rust commit we ran, while years of released use apply mainly to the C++ line. A conservative team can install v2.42.1 and wait for the 3.0 release. A team evaluating main should pin commit 54b68f6, store the old linker path, and avoid treating a moving branch as a released package.
The speed case is credible, but measure your own link step
The project's August 2026 benchmark reports mold at a 4.9x median advantage over LLVM lld and 1.9x over wild across its chosen programs and machines. Those are maintainer measurements, not results from our sandbox. Our run measured installation, compilation, and tests only. We did not link Chromium, Blender, or another large application, so we have no independent speed figure to attach to your build.
Linkers affect only the final stage after source files become object files. If compilation dominates a 10-minute build, cutting a small link step will barely move the total. Mold is most appealing when repeated debug builds pause at a large final link. Before changing a team default, capture link-only time, total build time, output size, debugger behavior, and one clean rebuild with the existing linker. That comparison tells you whether the switch fixes the delay people actually feel.
Linker scripts still separate applications from system software
The v2.42.1 release notes say mold 3.x needs missing linker-script features before distributions can consider it for /usr/bin/ld, especially for kernels and firmware. Open issue 243 gives a concrete example: a SECTIONS script used by kvm-unit-tests was rejected as an unknown token. Open issue 1055 records the same boundary for a custom runtime. These are specific compatibility gaps, not vague worries about a young tool.
Incremental linking is also absent. The release notes say the maintainers are exploring designs and would add it if they find a simple approach. That wording is an aspiration, not a delivery promise. For ordinary user-space ELF programs, the supported drop-in path is already useful. For bare-metal layouts, kernel work, or build systems built around GNU ld scripts, test the exact script before spending time on speed comparisons.
Current activity is strong while compatibility work remains open
GitHub showed 17,153 stars, 167 open issues, and 17 open pull requests on September 19, 2026. The repository was pushed that same day, and v2.42.1 had shipped 8 days earlier. Those figures point to active maintenance and an engaged user base. They also describe a project in the middle of an implementation change, with compatibility reports spanning debuggers, LTO, linker scripts, and particular large builds.
mold is easy to recommend as an experiment because the escape route is simple: remove the linker flag and rebuild. Our 40-second install and fully passing suite lower the cost of that experiment. The case for a machine-wide replacement is weaker until your complete software set has passed. Start with the slowest application link you own, verify the binary and its debug path, and let that result decide whether mold goes any farther.