mold is very, very fast.
What kind of dev team doesn't multitask?
Apart from edge-cases involving linking large projects synchronously, there's no competitive advantage and the feature set is far less than lld, bfd, or even gold. It's a niche "product" most people don't need.
Many projects don't have cutting edge build systems.
I'm also not committing temporary code just to make the CI produce a build that I'll need to download. I'll build locally.
What you’re suggesting is certainly the ideal case, but there are lots of things that can happen between where you are and where you want to end up. Saying that somebody isn’t a professional developer just because they haven’t reached the ideal state yet is bullshit.
It’s also easy to go around telling other people what they are or aren’t when you haven’t had the responsibility of building these building blocks yourself. You’re the user of them, not the creator of them. Have some respect for the giants whose shoulders you’re standing upon.
Do you not have automated unit and integration testing?
Do you not have code review and CI before code lands?
Do you not have distributed, cached, incremental builds?
Improving build time isn’t just about changing 30-minute builds to 30-second builds, but also about changing 30-second builds into 2-second builds.
While I often do finish other development related tasks during longer builds, it doesn't make sense to context switch to something completely different during a 1-2 minute delay. I will build dozens of times a day while testing or optimizing functionality, so this can really add up.
That said recent versions of clang + lld + fission result in <20 sec compile+link times even on a multi-gigabyte executable, so the need for mold is significantly lessened. Users that are currently using gold will see a dramatic improvement.
That's what async CI/CD unit and integration testing are for.
Also, it depends on the platform. Go doesn't have this problem. Rust does, to a degree. Interpreted languages make a linker moot.
The primary use case for mold is giant projects with massive executables. It's not a general-purpose linker, it can't improve inefficient workflows lacking automation, and it can't improve the multitasking of developer time for people who insist on waiting around instead of doing something else useful.
Ok, so what’s the point of contention here? Large projects from large companies with lots of money stand to benefit from mold.
It does.
In incremental builds, most of the time are spent in linking, not building.
I understand that using the linker purely for trying it out internally and not actually distributing anything linked by it would not trigger the AGPL in the same way that using it in production would, but our general policy is to err on the side of safety when it comes to things like this; for example, despite longing for some of the unstable features of the nightly version of rustfmt like being able to auto-merge imports, we currently don't use it due to not wanting anything related to the nightly toolchain in the CI we use for release builds in order to be extra sure that we don't accidentally ship anything unstable (think of it sort of like a layer of "defense in depth" for the build processes due to our product being in a highly sensitive security domain). The bad reputation that larger companies have with regards to free software licenses (which in many cases is probably deserved) means that the managers and teams who genuinely want to respect licenses and be community members and therefore would be the ones who normally _would_ be ideal customers for products like this instead tend to be incredibly risk averse about GPL-related software precisely because we want to avoid being part of the problem. I'm not really sure what the long-term solution here is, but I feel like the only path out of this local minimum is for both potential developers and customers of free software to signal eagerness to engage with potential partners on the other side in good faith. Instead, my reading of most of the communications about mold's commercial potential seem to be proactively defensive with a tinge of resentment. I fully empathize with these feelings and probably would feel the similarly if not even stronger in the same situation, but ultimately that's why I have no personal interest in pursuing entrepreneurship myself; being in the right isn't always going to be sufficient for succeeding in business, and sometimes the best strategy will be to be to give the benefit of the doubt even if it hasn't yet been earned.
From the README.md:
mold is available under AGPL. Note that that does not mean that you have to license your program under AGPL if you use mold to link your program. An output of the mold linker is a derived work of the object files and libraries you pass to the linker but not a derived work of the mold linker itself.
If it were a derived work, like maybe mold produces a binary that yanks some mold code, the story would be different: https://www.gnu.org/software/bison/manual/html_node/Conditio...