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.
This article was first published on Tech AI Wire.
Also available in
Deutsch · 日本語 · Français · Español · Português
Related on Tech AI Wire
- Bun 1.4 ships the AI-driven Rust rewrite to production
- YSERVER 1.5 adds Reverse PRIME to its Rust X11 server
Top comments (0)