That's your choice and your responsibility. You don't get to bind upstream, at least not without paying money. You can't say Rust is a bad solution, just because you developed a bootstrap chain that happens to find useful the fact that mold is written in C.

I have been thinking about Rust bootstrapping recently. Couldn'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).

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.

It seems like you would benefit from having reproducible and hermetic builds with a good caching layer so you don'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.

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?

>Rust is not actually the right tool for all problems.

"my problems (that are not mold's) are not solved by mold. How dare mold make those decisions?"

Maybe you should rewrite more of your linux distribution in rust so it's available earlier in the build process and get back to it being the default linker.

I'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're doing, given the resources they have.

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

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

> fixing corrupted input handling in a C/C++ code base would not be too hard

The best programmers on the planet have tried and failed with this task for 50 years now, so I don't think this is true.

The main disadvantage of Rust right now is not supporting some more obscure platforms, but because mold wouldn't support them anyway I don't see that as a problem.

My very naive understanding is that a part of what makes mold fast is concurrency, which I'd expect to be a lot more error-prone in C/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

It's possible to write safe code in C or C++ but it's extremely difficult to read existing code and prove it'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.

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

> in a C/C++ code base

It's like "in a Zodiac boat / aircraft carrier navy". This customary putting C and C++ into the same bucket is as amusing as it is unproductive.

> And second, did you use any AI tools for the rewrite?

IMO, given the recent commits: almost certainly.

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

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.

new???

The days when AI always means slop are gone. It still often does, but the latest models can be used to get very high quality code in many situations. I haven't checked the code here but I would be surprised if it's bad.

This is NOT a slop linker, Mold is a reference in the world of linkers and this port is official.

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.

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'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's changes to mold today after 3.0 release, they just modify the mold source code in Rust, as you'd expect if this was in fact now written in Rust.

No it doesn't.