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?

▲

fotcorn 4 hours ago | parent | next [-]

> 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 4 hours ago | parent [-]

> 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?

▲

fotcorn 3 hours ago | parent | next [-]

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.

Rewrite all the things!

	▲	afdbcreid 28 minutes ago \| parent [-]
		The GCC backend is fairly complete but still does not support everything.

▲

torginus 3 hours ago | parent | prev [-]

yeah this makes no sense to me. Why would Rust limit the LLVM backend's ability to generate code for a particular platform?

▲

panzi 3 hours ago | parent | next [-]

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.

	▲	bkallus 3 hours ago \| parent [-]
		> Don't ask me which 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.

▲

steveklabnik 2 hours ago | parent | prev [-]

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.

▲

saghm 4 hours ago | parent | prev | next [-]

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

▲

someonebaggy 2 hours ago | parent | prev | next [-]

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. The problem is not writing the code, it is continually verifying it.

▲

pornel 4 hours ago | parent | prev | next [-]

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 4 hours ago | parent | prev | next [-]

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

IMO, given the recent commits: almost certainly.

▲

marsven_422 3 hours ago | parent | prev | next [-]

[dead]

▲

nine_k an hour ago | parent | prev [-]

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

	▲	pjmlp an hour ago \| parent [-]
		Unfortunately too many folks still do C style programming in C++.