Mold Linker Version 3.0.0 Release – Rewritten in Rust

uncle_kostya

I'm curious about motivation - bounds checks for corrupted inputs seems like it would be one, but it also seems that fixing corrupted input handling in a C/C++ code base would not be too hard, and probably less of an effort? So why did you choose the rewrite? And second, did you use any AI tools for the rewrite?

Aissen

I 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...

awoimbee

So what differentiates mold from wild now ? Is wild using different data structures? (Wild is another fast linker, that only supports Linux)

mi_lk

Damn. I thought Zig would be a perfect rewrite language for Mold since it's a better C in many ways

lrvick

The linux distribution I co-maintain uses mold as our bootstrap linker to bootstrap rust itself, and it saved us -hours- on long version-by-version build chains. Mold being in c meant we could build it very early and use it as the default linker distro wide and enjoy build speedups everywhere. Now sadly we will have to fork and maintain the c version as mold2 forever. Rust is not actually the right tool for all problems.

WhereIsTheTruth

It was transpiled, not rewritten, rewrite implies by hand

sharktheone

Oh what? That was not on my bingo card for 2026. Mold already was incredible when it still was in C++ and I assume it is even better now that it is in rust

BoingBoomTschak

Pleasantly surprised to see a ~600 lines Cargo.lock (vs 2200 for wild, for example) here! Hope it can slim it down further. Something I really look into because the crates situation (due to a too small stdlib à la R5RS Scheme) is Rust's Achilles' heel, since it directly affects its security claims.