<a href="https:&#x2F;&#x2F;stagex.tools" rel="nofollow">https:&#x2F;&#x2F;stagex.tools</a>In short, the entire distro is always built in one-shot at any given commit, and we can only rely on cached binaries from a past release if they or nothing in their supply chains changed. Given rustc depends on almost everything, mold3 would be built far too late to be useful for the most expensive build in the whole tree, which is rust.Recursive dependencies would break our threat model, so we cannot use any rust tools to bootstrap rust. We bootstrap rust from llvm which we bootstrap from gcc which we bootstrap from tinycc which we bootstrap from M2Planet and so on back to 186 bytes of machine code.Anyone getting a rust package from stagex must be able to build the entire tree up until that package and get the same hash, with no binary dependencies, thus removing any trust in maintainers.

Like some other commenters, I do not understand why using a cached binary isn’t sufficient. Why not use the mold3 binary and build that first, and then cache it and never rebuild it again? I’m guessing it has to do with hermiticity and build provenance guarantees in your distro.Do you have any reading material that you can share that might help me understand better? Docs for the distro, or an issue tracker I can search through?

We use the llvm linker, lld, to link mold at the earliest point we can, then use mold exclusively after that. We are an LLVM native distro so we build llvm right away as the system compiler used to build the whole tree instead of gcc.LLD would work fine for the whole tree, and did previously, but is much much slower than mold which is why we switched to mold.Having to build all dependencies of rust including python and openssl and everything else before being able to use mold erases most of the full-tree build speedups as the path to rust is already about 80% of the full tree build time.We are a distro that mandates independently verified 100% deterministic builds from source for any given release commit of the tree, so we have to build the whole tree several times for every release.

Agreed -- not my wheelhouse, but couldn&#x27;t you just build rust earlier in your process using LLD, then build mold, then build everything else?Would that meant that building rust is slower, but everything else is the same, and you don&#x27;t have to maintain a fork of another complex project?

Because mold is faster. Linking is a significant bottleneck when building large projects.

Why not use LLD for linking Rust? You already must have the LLVM for Rust to be buildable, so that do not add any dependency.

This exists: <a href="https:&#x2F;&#x2F;github.com&#x2F;thepowersgang&#x2F;mrustc" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;thepowersgang&#x2F;mrustc</a>.

I have been thinking about Rust bootstrapping recently. Couldn&#x27;t a Rust compiler without borrow checker be put together relatively easily?Assuming the source code contains no issues (which can be checked later once the Rust compiler is built), one could leave that piece behind, and take the shortest path from .rs to executed code (C transpilation, or even an interpreter).

Our tree is entirely reproducible and hermetic. In fact we are the only distro that does this 100%.The problem is changing any dependency of rust, even python or perl or musl or openssl or the llvm stack or any dependencies of the llvm stack have the potential of resulting in a different hash for rust.Any time a dependency is changed all decedents must be rebuilt. Which we must do very frequently. That is where mold saved us a ton of time.

It seems like you would benefit from having reproducible and hermetic builds with a good caching layer so you don&#x27;t do the same work again and again.Then you can just use the latest built version to build mold and the next version of rust.

The need here is bootstrapping. If mold is written in Rust you cannot even compile it.

If the need is well justified, maybe there is great chance to ask adding #[no_mangle] and extern C support? Since release is very fresh. If that is causing the problem. Or is some dependency the issue?

Bootstrapping rust with mold2 is going to be the likely play. My complaint is that now we must maintain mold2 forever now as mold3 rust edition is now incompatible with most of our tree which is made up of dependencies of rust.

Could you not either bootstrap rust with lld or bootstrap rust with mold2?

I am not finding any linkers by that name.

You could use <a href="https:&#x2F;&#x2F;github.com&#x2F;thepowersgang&#x2F;mrustc" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;thepowersgang&#x2F;mrustc</a> to get relatively modern Rust compiler (1.90 currently apparently, but every now and then that is updated). Then build newer rustc from there to reach the current 1.99.But I don&#x27;t get why some people are obsessed with bootstrapping. Yes it is good to be able to do it, but it isn&#x27;t something you need to do regularly.Especially since rust had a much better cross compilation story than C or C++ (not as good as go or zig though), so you don&#x27;t need to bootstrap on a new architecture, just cross compile to it. Furthermore, new architectures for hosting a compiler (as opposed to just a target, like microcontrollers) is a rare event. Just something that happens every few years.

how&#x27;s bootstrapping rust story nowadays?

It&#x27;s simply an ordering problem. When building the entire world from scratch, usually the C and C++ toolchains are built near the very first, and Rust toolchains built somewhat later. Anything written in Rust must come after the Rust toolchain is built. You need a linker as part of your C++ toolchain, so it must be written in a language ready to go at that point. If it is written in C, you are done. If it is written in Rust you have to wait. So a Rust-based linker can no longer be used from that very, very early C bootstrap.It&#x27;s not a big deal for normal users, where you have Rust ready to go. Kind of a bummer in this case, but this is a specialized one.

One of the explicit goals for Mold 3.0 is to promote its use as the default linker in Linux distributions, and bootstrapping complexity is certainly worthy of consideration in that realm.&gt; We will then conduct extensive compatibility testing and work closely with Linux distribution developers to make it practical for them to adopt mold as &#x2F;usr&#x2F;bin&#x2F;ld. Making this happen is one of our highest priorities for mold 3.x.

I&#x27;m a bit confused why a decision to decrease the maintenance burden of Mold by switching languages makes Rust the wrong tool here? Fearless concurrency sounds like a huge benefit for what they&#x27;re doing, given the resources they have.

They were solved by mold. And then mold decided to un-solve them.

&gt;Rust is not actually the right tool for all problems.&quot;my problems (that are not mold&#x27;s) are not solved by mold. How dare mold make those decisions?&quot;Maybe you should rewrite more of your linux distribution in rust so it&#x27;s available earlier in the build process and get back to it being the default linker.

And repeat that work every time you sync with upstream?

Luckily Mr Clanker can do most of the work for you at least (I myself have already had Claude&#x2F;Codex rewrite a couple of Rust projects in C, worked great)

There are classes of virus that are hard to detect. One is a compiler virus that passes itself from compiler to compiler. You only get rid of the vector by bootstrapping from 0.

Why do you need to bootstrap a toolchain to bootstrap a distro?I know this is common but it seems like either an aesthetic decision, or glibc cruft.

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.

&gt; Was the conversion assisted?Yes. Comment by mold&#x27;s author:<a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;comments&#x2F;1w45j6n&#x2F;comment&#x2F;p7ac568&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;comments&#x2F;1w45j6n&#x2F;comment&#x2F;p7ac5...</a>

He decided to use LLM assistance exactly because he&#x27;s an extremely competent guy.

Assisted, yes. Claude is a coauthor for some of the commits and I think he also said that explicitly. Vibe-coded, he claims not.

Was the conversion assisted? I get the sense that Mold&#x27;s author is an extremely competent guy and it would be quite feasible for someone like him to do it on his own.

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: <a href="https:&#x2F;&#x2F;github.com&#x2F;rui314&#x2F;mold&#x2F;commit&#x2F;f41bfcd5c72ca30cce6498e912d7513481f55a1f" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rui314&#x2F;mold&#x2F;commit&#x2F;f41bfcd5c72ca30cce6498...</a>

wild&#x27;s primary purpose is incremental linking, which it incidentally does not support at all, while still being faster than mold by a long shot.

Wild&#x27;s primary purpose is incremental linking - I guess now the primary difference is a race + subtle differences in performance between projects.

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

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

If it was transpiled there would be what GNU calls a &quot;preferred form&quot; of the linker source in which it wasn&#x27;t written in Rust.This is true for - as an example - the WUFFS GIF decoder. You can get C which decodes GIFs and was transpiled from WUFFS, but that&#x27;s awful code and nobody wants to modify that code, whereas the WUFFS source code for the decoder is fine.When we look at rui314&#x27;s changes to mold today after 3.0 release, they just modify the mold source code in Rust, as you&#x27;d expect if this was in fact now written in Rust.

It was transpiled, not rewritten, rewrite implies by hand

Part of the safety you get with Rust is runtime bounds checking, which is equivalent to Zig in &quot;safe&quot; mode.

Zig makes you choose that at build time. You can use safe builds for development to catch bugs, and fast builds for release. You can even use safe builds in of the release, and optimize hot paths with fast builds.In practice, projects written in Zig very much can choose both.

That’s not entirely true. There’s a third choice. You can go the TigerBeetle route (TigerStyle). Zig is extremely well suited for software where you just avoid dynamic memory allocation all together. It’s extremely fast, very effective and arguably very safe. But not suitable for all applications obviously.There’s also another caveat that there’s an effort to build in build time static memory safety checks in a way that’s more general than Rusts borrow checker, through a kind of plug in system rather than forced into the language. It’s not part of mainline Zig yet but this seems to be the direction Andrew wants to go.<a href="https:&#x2F;&#x2F;github.com&#x2F;ityonemo&#x2F;clr" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ityonemo&#x2F;clr</a>

Zig makes you choose either safe or fast, not both. With Rust you can get both (generally).

Additionally, Zig just released 0.17, Rust&#x27;s 1.0 was 11 years ago. The choice may have been mostly for non-technical reasons.

When choosing a language, people don’t only look at language features but also at community adoption, the library ecosystem, industry backing etc.Zig isn’t even in the same league as Rust regarding these things. Zig may still be around and active 10 years from now, Rust is guaranteed to be.

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

&gt; The main disadvantage of Rust right now is not supporting some more obscure platformsLast time I checked, I got impressed by the wide platform support, once you go down the tier list (<a href="https:&#x2F;&#x2F;doc.rust-lang.org&#x2F;nightly&#x2F;rustc&#x2F;platform-support.html" rel="nofollow">https:&#x2F;&#x2F;doc.rust-lang.org&#x2F;nightly&#x2F;rustc&#x2F;platform-support.htm...</a>). What &quot;obscure platform&quot; specifically are you thinking about, that is currently missing from those lists?

&gt; fixing corrupted input handling in a C&#x2F;C++ code base would not be too hardThe best programmers on the planet have tried and failed with this task for 50 years now, so I don&#x27;t think this is true.The main disadvantage of Rust right now is not supporting some more obscure platforms, but because mold wouldn&#x27;t support them anyway I don&#x27;t see that as a problem.

My very naive understanding is that a part of what makes mold fast is concurrency, which I&#x27;d expect to be a lot more error-prone in C&#x2F;C++. Not having to worry about data races might give more confidence with trying out more complex techniques for how to split up work in a way that ends up making things faster

Is &quot;fearless concurrency&quot; a technical term? I thought it was just the catchy name of a chapter of the Rust book.

I suspect fearless concurrency is another motivating factor. Better perf can be achieved by squeezing more parallelism, but without borrow checking it&#x27;s difficult to do fine-grained parallelism correctly.

As someone who worked professionally with both C++ and Rust, I mostly agree with this, but I would say that writing the concurrent code in C++ is also hard.The only way I found that works reliably is stick to a small well defined set of mostly safe primitives. E.g. at work we use message passing &#x2F; event bus architecture everywhere, which works great for a robotics &#x2F; industrial context. But even then, if you somehow mess up and have a variable accessed from event handlers in two different threads, it is tough to spot other than if you get lucky and observe it with a build using TSAN.With rust that class of mistakes is just entirely eliminated, which makes it easier to to concentrate on the hard things that actually matter (like the domain specific logic).

It&#x27;s possible to write safe code in C or C++ but it&#x27;s extremely difficult to read existing code and prove it&#x27;s safe, without using as much effort as it takes to write it in the first place. This includes the code you wrote last month whose surrounding code has changed. And you have to be right every time while the attacker only needs you to be wrong once. The problem is not writing the code, it is continually verifying it.

&gt; And second, did you use any AI tools for the rewrite?IMO, given the recent commits: almost certainly.

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 &#x27;regular&#x27; source code), so technically C&#x2F;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&#x27;t have a concept of varargs?), so it could be called a C&#x2F;Rust project ;)<a href="https:&#x2F;&#x2F;github.com&#x2F;rui314&#x2F;mold&#x2F;tree&#x2F;main&#x2F;c" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rui314&#x2F;mold&#x2F;tree&#x2F;main&#x2F;c</a>

Unfortunately too many folks still do C style programming in C++.

&gt; in a C&#x2F;C++ code baseIt&#x27;s like &quot;in a Zodiac boat &#x2F; aircraft carrier navy&quot;. This customary putting C and C++ into the same bucket is as amusing as it is unproductive.

I&#x27;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&#x2F;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?

Mold Linker Version 3.0.0 Release – Rewritten in Rust