https://stagex.tools

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.

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'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't have to maintain a fork of another complex project?

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

This exists: https://github.com/thepowersgang/mrustc.

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.

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.

I am not finding any linkers by that name.

You could use https://github.com/thepowersgang/mrustc 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't get why some people are obsessed with bootstrapping. Yes it is good to be able to do it, but it isn'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'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.

Yep that is what we are going to have to do. Is what it is. Thanks for maintaining an amazing linker, and we will surely ship v3 at the last mile for end users.

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

And repeat that work every time you sync with upstream?

It'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'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.

> We will then conduct extensive compatibility testing and work closely with Linux distribution developers to make it practical for them to adopt mold as /usr/bin/ld. Making this happen is one of our highest priorities for mold 3.x.

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.

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

> Was the conversion assisted?

Yes. Comment by mold's author:

https://www.reddit.com/r/rust/comments/1w45j6n/comment/p7ac5...

He decided to use LLM assistance exactly because he'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.

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

> If it was transpiled there would be what GNU calls a "preferred form" of the linker source in which it wasn't written in Rust.

No, that's only sometimes true. If you like the transpiled version and start editing it directly then that's the new preferred form, but it was still a transpile to get from one language to the other.

Part of the safety you get with Rust is runtime bounds checking, which is equivalent to Zig in "safe" 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.

https://github.com/ityonemo/clr

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

> The main disadvantage of Rust right now is not supporting some more obscure platforms

Last time I checked, I got impressed by the wide platform support, once you go down the tier list (https://doc.rust-lang.org/nightly/rustc/platform-support.htm...). What "obscure platform" specifically are you thinking about, that is currently missing from those lists?

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

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 / event bus architecture everywhere, which works great for a robotics / 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).

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

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