Mold 2.42.1 shipped on September 11, and the interesting part of the announcement is not the patch release. It is what comes after it.

Mold 3.0 is a rewrite from C++ to Rust, and it carries a goal considerably more ambitious than the language change: becoming the default /usr/bin/ld on Linux distributions.

The admission

Rui Ueyama wrote both lld and mold, which makes his framing of the problem unusually pointed:

“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. As a result, 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. I think this is an unfortunate situation for the Linux community.

As the original author of both lld and mold, I think I bear some responsibility for this situation. I have spent 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.”

That is a rare thing to read from a project author: a diagnosis that the bottleneck was never performance, and that the work nobody wanted to do was compatibility.

It is also correct. Fast linkers have existed for two decades. Almost nobody gets one by default. You get it by knowing it exists, installing it, and adding -fuse-ld=mold to your build flags, which means the benefit goes to developers who already read about linkers and not to everyone else.

What “drop-in” actually requires

The concrete blocker Ueyama names is linker script support, needed so mold can link not just userspace programs but kernels and firmware.

Linker scripts are the part of the toolchain most application developers never touch and every embedded and kernel developer depends on. They control exact memory layout: where sections land, what addresses they start at, which symbols mark the boundaries. A kernel image is not just code linked together, it is code linked together in a specific arrangement that the bootloader and the hardware expect.

A linker that cannot execute those scripts faithfully cannot be the system linker, no matter how fast it is, because the distribution has to build its own kernel with it.

After that comes extensive compatibility testing and, in his words, working closely with distribution developers to make adoption practical. That is a multi-year programme, not a release.

Incremental linking, cautiously

Mold has never supported incremental linking, and the project is now exploring it:

“That said, if we can find a simple way to add incremental linking to mold, we would be happy to do so. It could still improve some workloads significantly. We are currently exploring designs that can provide those benefits while preserving mold’s simplicity and reliability.”

The hedging is the interesting part. Incremental linking is a classic source of subtle, hard-to-reproduce bugs, because the linker is reusing state from a previous run and has to be exactly right about what changed. Mold’s reputation rests on being fast and boringly correct. Trading the second for more of the first would be a bad deal, and the phrasing suggests they know it.

Why Rust, and where this sits

Ueyama cites Rust’s safety guarantees. A linker parses untrusted object files and does a great deal of pointer arithmetic over mapped memory, which is a fair description of a place where memory-safety bugs live.

Mold is not first. The Wild linker is already written in Rust and pursuing similar performance goals.

The wider pattern is hard to miss this month. Ubuntu completed its Rust coreutils transition, Google is deleting its C Binder driver in favour of the Rust one, Canonical is funding C-to-Rust translation research, and NVIDIA shipped CUDA Rust. The toolchain was one of the last layers untouched by it.

Trying it now

You do not have to wait for 3.0.

# Debian/Ubuntu
sudo apt install mold

# use it for one build
mold -run make -j$(nproc)

# or tell the compiler directly
gcc -fuse-ld=mold main.c -o main
clang -fuse-ld=mold main.c -o main

The difference is most noticeable on large C++ projects with heavy template use, where link time can exceed compile time and where the edit-build-test loop is dominated by the linker rather than the compiler.

If mold does eventually become /usr/bin/ld, the people who benefit most are the ones who never configured anything, which is rather the point.