rui314

When I announced the rewrite, it was actually already mostly done.

AI's coding ability is truly amazing. We've spent decades inventing languages, tools, and methodologies to help us write better code more efficiently, but AI-assisted coding is the biggest breakthrough in programming productivity I've seen in my lifetime. It's genuinely incredible.

That's unfortunate, and I'm sorry the Rust rewrite makes StageX's bootstrap more complicated. StageX has a fairly specialized requirement here, though, and I don't think it would make sense to keep mold in C++ just for that use case.

Using the final mold 2.x release as a bootstrap-only linker and then replacing it with mold 3 once Rust is available seems like the most practical compromise.

I think the way I've talked about incremental linking may have given a somewhat misleading impression. I'm not against incremental linking, and I'm not denying its possible usefulness. But especially when I was developing lld, I felt that we should focus first on speeding up full links.

Before I created lld, linking was much slower than it is today, and people somehow seemed to accept that as a given. People would often argue that since linking was slow, we needed to reduce the amount of linking work by implementing incremental linking. I thought that was too pessimistic. Why don't we just make the usual full link much faster, ideally almost as fast as a cp command, so that we don't need incremental linking nearly as much?

In other words, I wanted to solve the slow link problem head-on rather than work around linker slowness. And now we can link multi-gigabyte binaries in a second or two, which makes incremental linking much less urgent than it was ten years ago. That's pretty much what I wanted to achieve.

Am I satisfied with the speed? No. Could incremental linking speed it up even more? Maybe. Would it still be useful? Sure. It may well be worth doing. But people don't need it nearly as badly as they did ten years ago. I wanted to solve the larger problem first.

mold supports LTO out of the box.

Thanks, I really wish you become a billionaire :)

I don't know the details, but once it is proven that achieving lld/mold/sold-level performance is technically feasible, it shouldn't be extremely hard to achieve similar success for macOS.

> But it is no longer updated, is it?

Essentially, yes, but that’s because Apple’s new linker is so much faster than it was. You can use it instead.

The sold linker is no longer commercial software; it's been relicensed under the MIT license.

CRT object files which contain process startup routines are not in a fixed directory. Unfortunately compilers have to be hard-coded to contain an appropriate directory name.

It caused a flame war, so #1 factor is not negligible.

I could buy bikes too, but as you wrote that's not enough to make a living. This is my full time project. I could earn a mid 6 figure salary if I work for a big tech, and I think I'm creating a more valuable program than I did when I was working for a big tech, and in return I make money that counts in "fancy bicycle" unit... I think it's not wrong to say it didn't work quite well.

It didn't work. If it is available as open-source, they don't _need_ a different license. Anyway, it's off-topic.