Mold's Rust rewrite aims to be Linux's default linker

Rui Ueyama is rewriting mold, one of the fastest linkers available on Linux, from C++ into Rust. Phoronix reported on September 11, 2026 that the rewrite anchors mold's coming 3.x series. The second goal is the one developers should watch: mold wants Linux distributions to install it as /usr/bin/ld, the default linker every build reaches for.

A linker is the last step of a build. The compiler turns each source file into an object file. The linker then stitches those objects and their libraries into one program you can run. On a large C++ or Rust project, that final step often decides how long you wait.

The gap is wide. Phoronix described it in concrete terms. A link job mold finishes in "a few hundred milliseconds" can take "several seconds, tens of seconds, or even minutes with the default linker."

The mold repository claims it links 4.9 times faster than LLVM's lld at the median, and 1.9 times faster than wild. Ueyama wrote lld as well, so he is competing against his own earlier work. The project has been in production use since 2021. It supports 14 CPU architectures, including x86-64, ARM, RISC-V, PowerPC, s390x, LoongArch and SPARC64.

Why Rust, and why now

Ueyama gave his reasons in a pinned discussion on mold's GitHub repository, started September 1, 2026. Memory safety came first. A linker reads object files it did not create and does heavy pointer arithmetic. That is exactly where a memory bug is easy to write and slow to find.

He also pointed at tooling. Rust ships Cargo for managing dependencies, and it makes cross-compilation simpler. Both matter for a tool that has to build for 14 architectures. C++20, mold's current language, gives him neither by default.

The timing argument is the one that will get argued about. Ueyama credits AI coding tools with making the rewrite affordable at all. "AI-assisted rewriting has dramatically changed the cost of doing this kind of work," he wrote. "I probably wouldn't have attempted this last year, but today it takes surprisingly little effort."

He framed the choice as a long bet: "this decision will make more sense in retrospect 10 or 20 years from now than it may seem today."

Other projects have taken the same route this year. Bun 1.4 shipped its Rust rewrite to production in August, and YSERVER 1.5, an X11 server written from scratch in Rust, had its early code written with AI help.

Becoming /usr/bin/ld is the harder half

Speed is not what stops a linker from becoming the default. Compatibility is. GNU ld and its faster sibling gold have decades of accumulated behavior that build scripts quietly depend on, from linker-script syntax to obscure command-line flags.

The project knows this. "One of the main goals of the mold 3.x series is to make mold suitable for adoption as /usr/bin/ld by Linux distributions," Phoronix reported. The plan after the rewrite is slow and social: "We will then conduct extensive compatibility testing and work closely with Linux distribution developers."

Step	Status
Rewrite mold from C++ into Rust	Underway, targeting the 3.x series
Extensive compatibility testing	Planned, after the rewrite
Coordination with distribution developers	Planned, after testing
Shipping as /usr/bin/ld by default	Not scheduled

No distribution has committed to the switch, and no date has been given for any of these steps.

What this means for developers

Nothing breaks today. mold 2.x stays where it is, and the Rust rewrite lands in a future 3.x series that has no release date.

If you have never tried mold, this is a good week to measure what it would save you. On a Linux toolchain you can point a single build at it with -fuse-ld=mold, then compare the link step against your current default. Projects with many object files and large static libraries see the biggest difference; a small project may see none.

If you maintain a build system or a distribution package, the compatibility phase is where your input matters. Custom linker scripts, unusual flags and link-time optimization settings are the parts most likely to differ. Ueyama has said explicitly that he wants distribution developers involved before any default changes.

There is a second thing worth noticing here, separate from linkers. A maintainer of a widely used systems tool has now said publicly that AI assistance changed what rewrite he was willing to attempt. Whether that judgment holds up is a question the 3.x series will answer in code, and it is worth checking against the result rather than the claim.