Mold rewrites its linker in Rust and aims to become Linux's default linker
Mold 2.42.1, published on September 11, 2026, is the last C++ release: version 3.0 will be rewritten in Rust with the stated goal of becoming /usr/bin/ld on most distributions. For heavy builders, that means links in a few hundred milliseconds instead of seconds or minutes.
September 11, 2026. Rui Ueyama publishes Mold 2.42.1, the fastest release of the linker he started in 2020 — and, if all goes to plan, the last one written in C++. The release notes carry two heavyweight decisions: a full rewrite in Rust to be shipped as Mold 3.0, and an explicit goal — making mold the default /usr/bin/ld on Linux distributions. This is not a language swap. It is a bet on two more decades of the compilation toolchain.
The last C++ release of a six-year-old tool
Mold has, since 2020, been the fastest linker on the market, ahead of LLVM lld and the newer wild, itself written in Rust. The 2.42.1 notes say so plainly: mold is “as fast as or faster than” its competitors. The release also lands fixes for LTO builds, debugging, and C++ exception handling.
But the substance is not in the fixes. It is in the roadmap. Ueyama writes that “2.42.1 is likely to be the last C++ version of the linker unless we need to make another patch release.” The Rust rewrite will ship as 3.0.
The reasoning fits in three sentences. A tool like mold may stay in use “for decades.” On that timescale, mold is still early in its life. And rewriting it in Rust now — when the language has matured — is the right moment; when Ueyama began in 2020, Rust was still “relatively new,” but by 2026 it offers performance comparable to C++ plus memory-safety guarantees.
Becoming the default linker: the real goal of the 3.x series
The rewrite is only the means. The target is the /usr/bin/ld of your distribution.
Ueyama’s assessment is blunt: “Over the past 20 years, several fast linkers, including gold, lld, and mold, have been developed. Yet the system linker, /usr/bin/ld, on most Linux distributions is still GNU ld.” The direct consequence: “link jobs that mold can finish in a few hundred milliseconds may still take several seconds, tens of seconds, or even minutes with the default linker.”
He accepts his share of responsibility. As the original author of both lld and mold, he admits to spending “a great deal of effort making linkers faster, but not enough effort on the compatibility work needed to make a fast linker suitable as a drop-in replacement for the system linker.” The 3.x series is meant to change that.
The technical path is known: implement the linker-script features that are still missing, so that mold can link not just user-space programs but also kernels and firmware. Extensive compatibility testing and close work with distribution maintainers follow. That, he writes, is “one of our highest priorities for mold 3.x.”
The detail matters. It is precisely on these linker scripts that ld.gold and then lld historically stumbled when some distributions tried to make them the default link — kernels and firmware rely on script idioms that the “modern” linkers did not cover.
A rewrite owned openly, not a leap of faith
Rewriting an established program carries risk, and Ueyama does not downplay it. “Recent advances in AI-assisted coding have made large-scale rewrites considerably more practical, but they do not eliminate those risks,” he writes. Trust is mold’s capital: “People trust mold because it just works, and we cannot afford to lose that trust.”
The contract with users is explicit: from the builder’s point of view, mold 3.0 must behave exactly like 2.x, with only the implementation changing under the hood.
On incremental linking, the tone also shifts. Ueyama clarifies he was never against it — he first wanted full links fast enough to “approach the speed of a simple file copy.” If a simple approach to incremental linking can still improve some workloads “significantly,” the team will explore it, provided it preserves “mold’s simplicity and reliability.”
What this changes for you
- If you build C++ or Rust at scale (monorepos, long CI builds), switching to mold remains the cheapest lever on link time today. 2.42.1 is a safe choice; the rewrite changes nothing about its behavior.
- If you maintain a distribution, the 3.x series is aimed directly at you: Ueyama’s promise is the compatibility work that
lldnever fully completed on kernels and firmware. Watch for the alphas. - If you run a pinned build chain, keep an eye on the calendar: 2.42.x stays the reference C++ branch for the whole transition to 3.0.
The watchpoint lies elsewhere. A rewrite partly driven by AI on a component as central as the linker deserves close observation: the advertised productivity gains do not remove the need for human review of the critical paths — linking is not a component where a subtle defect stays consequence-free.
Verdict
Mold 2.42.1 is a continuity release: adopt it if you are already on mold, trial it if you want faster builds without changing anything else.
The decision that matters is 3.0. If you build kernels, firmware, or system code and you want a faster ld, follow mold 3.x’s alpha releases — that is where the compatibility that will (or will not) make mold Linux’s default linker is won. If you are simply squeezed by CI time, do not wait for the rewrite: 2.42.1 already delivers the gain today, without the risk.