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.
Rust is not actually the right tool for all problems.
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?
> 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.
> 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?
Just to be clear, I think this is a very small disadvantage. GCC and therefore C/C++ supports some old stuff like SuperH, Intel Itanium, PA-RISC and a bunch of microcontroller archs that LLVM does not.
However, there is now a Rust codegen plugin for GCC, so even this disadvantage is now basically moot.
I think the claim is that GCC supports a few obscure platforms that LLVM doesn't. Don't ask me which, that is just the claim that I heard multiple times. So it's not Rust that limits platforms, but LLVM. And they say the GCC backend efforts of Rust are meant to deal with that.
There are many. Two big ones are Alpha and PA-RISC. NetBSD and Linux continue to support both. Linux distro choices are pretty much limited to Gentoo though.
1. You've got the causality backwards. LLVM backends don't come for free, you have to write code to enable support for them.
2. LLVM does not support as many backends as GCC does, so even if you did get 100% of the LLVM supported backends up and running, you'd still be missing some.
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
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.
What warrants an off the cuff comment like this?
I can take any piece of software and just say a vague statement like that. All of software... What does it even bring to the conversation? Just vague "they"s again we keep on propping up? Who is unethical? The mold team? The AI? The rust foundation? The ASCII character set? The cloud system it has been compiled on? Oh no obviously the backdoors in there?! Oh let us guess!!
2. Most of those are obviously LLM-induced, unless there's a new breed of human trained on just the failures of LLMs and not the successes or other relevant information
3. I therefore assume that the rest of the project is an unverified LLM psychosis without meaningful human review
That's not the worst thing in the world for all software maybe. I recently found out my apartment complex in their latest AI rewrite generates SMS OTP based purely on the timestamp and ignores passwords, so I can log in as anyone else by knowing their email and having a valid email to grab the current OTP. That's a major security failing, but how bad is it really? I can grab the last-4 of their credit card numbers, pay their rent, see how much other tenants are being screwed, and so on, and only if I know their email addresses (solvable with a tiny bit of social engineering, but let's assume that's also moderately hard). How bad is that really? On the one hand, it's terrifying, since I presume they have the same level of attention to detail with respect to payment methods and PII despite my having opted out of having them stored, but (a) that's all already been exposed via dozens of breaches and is being handled behind the scenes by my bank anyway, and (b) if we examine the immediate blast radius of the known bugs then there's approximately fuck-all an attacker can do with that information.
For a multi-threaded linker? Come the fuck on. I don't care if it's written in Rust. If you ignore all of the memory ordering intrinsics and `unsafe` then maybe it's more okay, but not having easily available UAF and other memory bugs is very different from actually implementing the correct behaviour, and for a linker where you're explicitly joining together multiple independent binary blobs and choosing what and how to execute on a machine instruction level, Rust's guarantees 100% don't save you from broken, unvalidated "business logic."
Now sadly we will have to fork and maintain the c version.
Rust is not actually the right tool for all problems.
Edit: this seems to have been cooking for a while when the first commit dropped: https://github.com/rui314/mold/commit/f41bfcd5c72ca30cce6498...
(Wild is another fast linker, that only supports Linux)
And second, did you use any AI tools for the rewrite?
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.
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?
However, there is now a Rust codegen plugin for GCC, so even this disadvantage is now basically moot.
Rewrite all the things!
There are many. Two big ones are Alpha and PA-RISC. NetBSD and Linux continue to support both. Linux distro choices are pretty much limited to Gentoo though.
2. LLVM does not support as many backends as GCC does, so even if you did get 100% of the LLVM supported backends up and running, you'd still be missing some.
IMO, given the recent commits: almost certainly.
LLM are excellent translation tools. Nothing is learned or stolen from them out of this exercise if this is a copyright issue you are getting at.
Then Rust? Why picking on it, the language is morally corrupt? In what way? If it were a rewrite in Object Pascal it would be better?
1. There are major obvious flaws
2. Most of those are obviously LLM-induced, unless there's a new breed of human trained on just the failures of LLMs and not the successes or other relevant information
3. I therefore assume that the rest of the project is an unverified LLM psychosis without meaningful human review
That's not the worst thing in the world for all software maybe. I recently found out my apartment complex in their latest AI rewrite generates SMS OTP based purely on the timestamp and ignores passwords, so I can log in as anyone else by knowing their email and having a valid email to grab the current OTP. That's a major security failing, but how bad is it really? I can grab the last-4 of their credit card numbers, pay their rent, see how much other tenants are being screwed, and so on, and only if I know their email addresses (solvable with a tiny bit of social engineering, but let's assume that's also moderately hard). How bad is that really? On the one hand, it's terrifying, since I presume they have the same level of attention to detail with respect to payment methods and PII despite my having opted out of having them stored, but (a) that's all already been exposed via dozens of breaches and is being handled behind the scenes by my bank anyway, and (b) if we examine the immediate blast radius of the known bugs then there's approximately fuck-all an attacker can do with that information.
For a multi-threaded linker? Come the fuck on. I don't care if it's written in Rust. If you ignore all of the memory ordering intrinsics and `unsafe` then maybe it's more okay, but not having easily available UAF and other memory bugs is very different from actually implementing the correct behaviour, and for a linker where you're explicitly joining together multiple independent binary blobs and choosing what and how to execute on a machine instruction level, Rust's guarantees 100% don't save you from broken, unvalidated "business logic."
Hope you're posting this from a GNU Hurd system or some other luddite-appoved zeroes and ones. You wouldn't want to be a hypocrite.