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?
saghm 29 minutes ago [-]
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
fotcorn 34 minutes ago [-]
> 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.
embedding-shape 32 minutes ago [-]
> 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?
torginus 23 minutes ago [-]
yeah this makes no sense to me. Why would Rust limit the LLVM backend's ability to generate code for a particular platform?
panzi 17 minutes ago [-]
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.
pornel 34 minutes ago [-]
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.
LoganDark 45 minutes ago [-]
> And second, did you use any AI tools for the rewrite?
IMO, given the recent commits: almost certainly.
acedTrex 34 minutes ago [-]
unfortunate world we live in, the amount of trustable/ethical software is going to near zero.
gbin 13 minutes ago [-]
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!!
acedTrex 10 minutes ago [-]
I didn't think it needed to be said... If you need it spelled out the LLM rust rewrite is very clearly what is being referred to.
boxed 7 minutes ago [-]
The fact that it's less C++ and more rust makes it more trustable and more ethical, not less.
Rendered at 15:48:45 GMT+0000 (Coordinated Universal Time) with Vercel.
Edit: this seems to have been cooking for a while when the first commit dropped: https://github.com/rui314/mold/commit/f41bfcd5c72ca30cce6498...
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?
IMO, given the recent commits: almost certainly.