Apparently the old mold version had a couple of plain C source files in the source tree (both vendored 3rd party libs but also in the 'regular' source code), so technically C/C++ is correct in this case ...and looks like the Rust version also has some (very minimal) C code left (looks like mostly varargs stuff, I guess Rust doesn't have a concept of varargs?), so it could be called a C/Rust project ;)
https://github.com/rui314/mold/tree/main/c
In Mold Linker Version 3.0.0 Release – Rewritten in Rustrui314
mold
Rust2020–2026
rui314 / mold
mold
mold 🦠: A Modern Linker in Rust 🦀
80Distinct people
95Mentions
0Explicit recommenders
17.7KGitHub stars
What to know before exploring
What it is
mold 🦠: A Modern Linker in Rust 🦀
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- mozilla/sccache · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year95 dated mentions
Observed mentions: 2020-12-13 19:21:00 UTC to 2026-10-05 20:22:21 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 15 | 7 | 8 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 34 | 8 | 26 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 20 | 4 | 16 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 9 | 5 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 7 | 2 | 5 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
mold: A Modern Linker
mold is a high-performance drop-in replacement for existing Unix linkers,
designed to speed up builds. In our August 2026 benchmarks, it links 4.9x
faster than LLVM lld and 1.9x faster than
wild at the median; see
Benchmark for the full results.
mold is written by the original developer of LLVM lld, the linker that
Android, Chrome, FreeBSD, PlayStation, Nintendo Switch, and other production
systems are built with. mold started as an effort to build an even faster
linker from scratch, free of the architectural limits its author had run into
while optimizing lld. It has been in production use since 2021, and today it
is the default linker of many large open-source projects and is used
internally by many companies.
mold supports x86-64, i386, ARM 32/64, RISC-V 32/64, PowerPC 32/64, s390x,
LoongArch 32/64, SPARC64, m68k, and SH-4.
Why does linking speed matter?
If you are using a compiled language such as C, C++, or Rust, a build consists
of two phases. In the first phase, a compiler compiles source files into
object files (.o files). In the second phase, a linker takes all object
files and combines them into a single executable or shared library file.
The second phase can be time-consuming if your build output is large. mold can
speed up this process, saving you time and preventing distractions while
waiting for a lengthy build to finish. The difference is most noticeable
during rapid debug-edit-rebuild cycles.
Benchmark
Here is a performance comparison of lld, wild, and mold when linking nine
large programs on two machines:
AMD Ryzen Threadripper 7980X (64 cores) running Ubuntu 24.04
Apple M1 Ultra (16 performance cores and 4 efficiency cores) running Fedora
Asahi Remix 42; the benchmark is restricted to the performance cores
The Threadripper represents many-core workstation and server processors, and
the M1 Ultra represents high-performance desktop processors.
All three linkers were built from source in release configuration as of
2026-08-28 and ran with their default options. Times are wall-clock times as
seen by the caller, the median of three runs after a warm-up. The ARM64 rows
are the ARM64 builds of the same programs. The benchmark suite, including all
linker inputs, is available on Zenodo.
AMD Ryzen Threadripper 7980X, debug builds
Program (output size)
lld
wild
mold
wild/mold
lld/mold
Blender 5.2 (2.46 GiB)
4.72s
1.98s
0.86s
2.3x
5.5x
Chromium 145 (4.51 GiB)
16.64s
3.98s
1.65s
2.4x
10.1x
Chromium 145 ARM64 (4.76 GiB)
20.91s
N/A
1.83s
N/A
11.4x
Clang 21 (4.19 GiB)
6.19s
3.71s
1.34s
2.8x
4.6x
ClickHouse 26.1 (5.58 GiB)
6.62s
4.40s
0.98s
4.5x
6.7x
Firefox 149 (2.37 GiB)
5.11s
N/A
0.78s
N/A
6.5x
Firefox 149 ARM64 (2.43 GiB)
6.40s
N/A
0.93s
N/A
6.9x
Godot 4.6 (1.01 GiB)
1.77s
1.08s
0.46s
2.3x
3.8x
LibreOffice 26.2 (0.98 GiB)
3.46s
1.41s
0.44s
3.2x
7.9x
PyTorch 2.9 (3.51 GiB)
4.35s
2.48s
0.80s
3.1x
5.4x
TensorFlow 2.21 (9.55 GiB)
50.73s
N/A
3.15s
N/A
16.1x
AMD Ryzen Threadripper 7980X, release builds
Program (output size)
lld
wild
mold
wild/mold
lld/mold
Blender 5.2 (0.24 GiB)
0.85s
0.30s
0.20s
1.5x
4.2x
Chromium 145 (0.58 GiB)
6.48s
N/A
0.64s
N/A
10.2x
Chromium 145 ARM64 (0.60 GiB)
7.91s
N/A
0.73s
N/A
10.8x
Clang 21 (0.21 GiB)
0.53s
0.23s
0.11s
2.2x
5.0x
ClickHouse 26.1 (1.23 GiB)
3.18s
2.07s
0.41s
5.0x
7.7x
Firefox 149 (0.22 GiB)
1.01s
0.41s
0.21s
2.0x
4.9x
Godot 4.6 (0.15 GiB)
0.44s
0.21s
0.08s
2.7x
5.8x
LibreOffice 26.2 (0.19 GiB)
1.13s
0.57s
0.19s
3.0x
6.0x
PyTorch 2.9 (0.31 GiB)
0.68s
0.32s
0.15s
2.2x
4.7x
TensorFlow 2.21 (0.73 GiB)
9.62s
N/A
0.70s
N/A
13.7x
Apple M1 Ultra, debug builds
Program (output size)
lld
wild
mold
wild/mold
lld/mold
Blender 5.2 (2.46 GiB)
3.21s
1.81s
1.56s
1.2x
2.1x
Chromium 145 (4.51 GiB)
9.54s
3.49s
2.22s
1.6x
4.3x
Chromium 145 ARM64 (4.76 GiB)
12.67s
N/A
2.31s
N/A
5.5x
Clang 21 (4.19 GiB)
4.40s
2.78s
2.96s
0.9x
1.5x
ClickHouse 26.1 (5.58 GiB)
4.92s
3.50s
1.71s
2.1x
2.9x
Firefox 149 (2.37 GiB)
3.21s
N/A
1.12s
N/A
2.9x
Firefox 149 ARM64 (2.43 GiB)
4.13s
N/A
1.12s
N/A
3.7x
Godot 4.6 (1.01 GiB)
1.12s
0.81s
0.62s
1.3x
1.8x
LibreOffice 26.2 (0.98 GiB)
2.08s
0.94s
0.63s
1.5x
3.3x
PyTorch 2.9 (3.51 GiB)
3.07s
2.10s
1.45s
1.4x
2.1x
TensorFlow 2.21 (9.55 GiB)
43.68s
N/A
4.43s
N/A
9.9x
Apple M1 Ultra, release builds
Program (output size)
lld
wild
mold
wild/mold
lld/mold
Blender 5.2 (0.24 GiB)
0.56s
0.20s
0.25s
0.8x
2.3x
Chromium 145 (0.58 GiB)
4.25s
N/A
0.78s
N/A
5.5x
Chromium 145 ARM64 (0.60 GiB)
5.17s
N/A
0.91s
N/A
5.7x
Clang 21 (0.21 GiB)
0.30s
0.15s
0.14s
1.0x
2.1x
ClickHouse 26.1 (1.23 GiB)
1.94s
0.95s
0.55s
1.7x
3.5x
Firefox 149 (0.22 GiB)
0.56s
0.23s
0.20s
1.1x
2.7x
Godot 4.6 (0.15 GiB)
0.26s
0.11s
0.11s
1.0x
2.3x
LibreOffice 26.2 (0.19 GiB)
0.62s
0.30s
0.23s
1.3x
2.7x
PyTorch 2.9 (0.31 GiB)
0.43s
0.22s
0.17s
1.3x
2.5x
TensorFlow 2.21 (0.73 GiB)
8.07s
N/A
0.68s
N/A
11.9x
N/A indicates that the linker cannot link that program. wild's Chromium
release links are also marked N/A because wild does not implement --icf=all
and links without identical code folding.
Why is mold so fast?
mold owes its speed to pervasive parallelism and to efficient data structures
and algorithms. For details, read our paper "mold: A Massively Parallel
Linker" (ASPLOS 2027), available at https://arxiv.org/abs/2608.23228.
Installation
Binary packages for the following systems are currently available:
Prebuilt binaries for Linux on x86-64, ARM64, ARM32, RISC-V, PPC64LE, s390x,
and LoongArch are also attached to each
GitHub release.
How to Build
mold is written in Rust and built with Cargo. It requires Rust 1.95 or later;
if your system's Rust is older, install the stable toolchain with
rustup. You also need Git and a C compiler such as GCC or
Clang, which you can install with your system's package manager.
Compile mold
git clone https://github.com/rui314/mold.git
cd mold
cargo build --release
The executable is target/release/mold.
Install mold
Run
Read the full README on GitHubWhat Hacker News says
95 sourcesPretty much every piece of open source software ships with a legal document saying that the software is provided as-is without any warranty or guarantee of functionality (i.e. https://github.com/rui314/mold/blob/main/LICENSE ). Unless I had a support agreement with the maintainers that superseded that document, I would not expect any special treatment from upstream. Personally, whenever I add a new dependency, I do it with the knowledge that I may have to either replace it or take on maintenance myself in the future.
In Mold Linker Version 3.0.0 Release – Rewritten in Rusthttps://github.com/rui314/mold/releases/tag/v2.42.1
"Recent advances in AI-assisted coding have made large-scale rewrites considerably more practical, but they do not eliminate those risks, and we do not take them lightly."
In Mold Linker Version 3.0.0 Release – Rewritten in RustI expected this to be a multi-months rewrite, not 3 weeks. I almost forgot we live in the agents era now.
Edit: this seems to have been cooking for a while when the first commit dropped: https://github.com/rui314/mold/commit/f41bfcd5c72ca30cce6498...
In Mold Linker Version 3.0.0 Release – Rewritten in RustMold Linker Version 3.0.0 Release – Rewritten in Rust
247 points · Open discussionOfficial mold linker rewrite in Rust
3 points · Open discussionHave you switched to a faster linker [0] yet? Do you use sccache?
[0] https://github.com/rui314/mold
In Performance of Rust Language [pdf]Wow. Has it been almost 20 years since the gold linker appeared?
LLVM's lld linker is typically faster. see https://llvm.org/devmtg/2017-10/slides/Ueyama-lld.pdf and https://lld.llvm.org/
The developer behind the lld linker then developed the mold linker - see https://github.com/rui314/mold and https://news.ycombinator.com/item?id=34382908
There's also the wild linker - see https://www.phoronix.com/news/Wild-Linker, https://github.com/davidlattimore/wild and https://news.ycombinator.com/item?id=42814683
In Linkers (2007)> I don't see what advantage this gives
I believe it may "just" be faster link times. Which may seem minor, but link times can often dominate incremental compile times because it's a slow and (at least historically) serial step which is O(total code size) even if the actual compilation is incremental.
See mold's linking benchmarks: https://github.com/rui314/mold. It can be the difference between multiple 10s of seconds with traditional linkers vs <2s with newers ones.
There are few strategies for dealing with this:
1. Is just to use a faster multi-threaded linker. On Linux, lld, mold, and wild on Linux are all much faster than the traditional ld/gold (and the latter two another step above lld). On macOS, the new built-in ld64 is pretty good. Not sure what the state is on Windows: possibly lld is best?
2. Is dynamic linking as above. This
Read the rest
seems to be faster even though the dynamic links need to resolved at runtime. I presume because at least the links wholly within the dynlib don't need to be resolved.
3. Is tools like Subsecond (https://github.com/DioxusLabs/dioxus/tree/main/packages/subs...) which effectively implement incremental linking by diffing the symbols in object files.
PSA: try https://github.com/rui314/mold
(Not affiliated with the project. Just switched to it and never looked back.)
In Goiaba: An experimental Go compiler, written in RustLink times are the worst part but solveable with mold[1]/sold. Incremental compilations are usually an order of magnitude (or even two) faster than clean compiles but tbh that can still feel slow. Helped by using something like sccache[2] or even cranelift[3] when debugging. Still not as fast as having a hot-reloadable language but it gets you to a relatively pleasant speed still IME
[1] https://github.com/rui314/mold
[2] https://github.com/mozilla/sccache
[3] https://github.com/rust-lang/rustc_codegen_cranelift
In Unexpected productivity boost of Rustthere are plenty of linkers that parallelize linking
https://github.com/rui314/mold?tab=readme-ov-file#why-is-mol...
https://llvm.org/devmtg/2017-10/slides/Ueyama-lld.pdf
In It is worth it to buy the fast CPU>well designed codebases
One thing to keep in mind is that what was well-designed 30, 20 or 10 years ago may not be considered such now. Hardware changes and so do the design decisions involving performance.
For example, if you are looking at C++ networking libraries, learning from ACE or even Asio may not be the best idea - better look at "thread per core, share nothing" Seastar[0].
Another thing is that it may be better to read design docs, not the code. For example, the rationale for the mold linker design[1].
[0] https://docs.seastar.io/master/tutorial.html#asynchronous-pr...
[1] https://github.com/rui314/mold/blob/main/docs/design.md
In Ask HN: Best codebases to study to learn software design?O(n) multi-glob pattern matcher based on bitvectors
1 points · Open discussionThis could speed up linking:
https://github.com/rui314/mold
In I wrote a commercial game in C in 2025Showing the 15 most recent of 95 sources. Enable JavaScript to search and browse every indexed mention.