3 comments

  • Aissen 23 minutes ago
    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: https://github.com/rui314/mold/commit/f41bfcd5c72ca30cce6498...

  • uncle_kostya 54 minutes ago
    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 30 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 35 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 33 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 24 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 18 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 36 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 46 minutes ago
      > And second, did you use any AI tools for the rewrite?

      IMO, given the recent commits: almost certainly.

  • acedTrex 35 minutes ago
    unfortunate world we live in, the amount of trustable/ethical software is going to near zero.
    • gbin 14 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 11 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 8 minutes ago
          The fact that it's less C++ and more rust makes it more trustable and more ethical, not less.