Well fair enough if they're trying to make enough money for this to be a business. I still suspect they won't succeed. How many businesses are so constrained by link times on Mac that they're willing to pay to reduce them? (And go through the admin effort of paying for something.) But I hope we don't see any tedious comments here about how this is a moral outrage because all software should be fr£e.
I don’t necessarily think software should be free. Info think that it is beneficial for discovery and for use of the software itself is for free. Exactly for the reason you mention, the administrative burden of paying for a license. Having to understand what it means if I want to run the software on build servers/ci/cd. How do I get lelicense files there etc.
If it just works and I need to make sure I shell over the appropriate amount for our usecase it will already be easier.
If I need to pay up front to see how much real world gain we would get I am much likely not to do it. (Looking at you EE graalvm specifically now.)
Apple themselves could take note and decide to negotiate a license for the sake of their customers. Businesses are often willing to pay for something that would ordinarily take an R&D team some NRE to develop. And Apple has a great deal of money. They could free it up for adventurous customers as soon as they negoiate terms. And the amount of work it would take to integrate it into the next generation of XCode (as a tested/verified alternative to ld64 via -fuse-ld=mold) would probably be pretty modest.
> But I hope we don't see any tedious comments here about how this is a moral outrage because all software should be fr£e.
All software should be free-as-in-freedom, but not nescessarily free-as-in-£; though I acknowledge that the former without the latter is often problematic. Plus, even beyond the "moral should", practically speaking, going non-FOSS this means it gets excluded from GNU/Linux distro packages, which IMO would be a fatal hit for something like this.
But honestly, I'm fine with this move. It's still FOSS for FOSS-systems, while support for non-FOSS systems is non-FOSS. The folks who care about free-as-in-freedom won't be affected by this. And even then, the non-FOSS `sold` is source-available, which covers 3 of the 4 freedoms; and IMO that missing freedom is the least important.
> I still suspect they won't succeed. How many businesses are so constrained by link times on Mac that they're willing to pay to reduce them? (And go through the admin effort of paying for something.)
A reasonable amount of software is "free-as-in-£ for personal use, paid for professional use." Lots of orgs are willing to ask individual devs "are there any dev tools you use that we should be paying for" and are willing to pay the $50/mo for IntelliJ, so $10/mo for `sold` seems to me like it stands a chance? Note that `sold` is still free-as-in-£ for use in CI/CD, and is only paid for individual-developer use.
> Note that `sold` is still free-as-in-£ for use in CI/CD
The relevant part of the EULA [1] states:
> Individuals who use the Software only occasionally, or non-interactive use of the Software that is not explicitly invoked by an individual such as CI/CD (continuous integration/continuous delivery), are not considered Active Interactive-use Users ("AIUs"). No additional fees are required for such uses.
I had to read it multiple times to understand the CI/CD bit. It's not clear to me whether the EULA says that CI/CD is an example of "use that is explicitly invoked by an individual" or if it's an example of "non-interactive use that is not explicitly invoked by an individual" - the wording is unclear to me and can have either of the opposite interpretations.
At my day job, we occasionally test C++ code changes by compiling in a CI/CD system to obtain a container image that we can push into a staging environment. This means we have a develop-compile-test cycle where the "compile" step involves pushing to a merge request branch, waiting for CI/CD to finish, and then running a deploy script to push out the newly-built image for testing. I wonder if this would be considered "Active Interactive-use Use" or not.
> It's not clear to me whether the EULA says that CI/CD is an example of "use that is explicitly invoked by an individual"
I agree that it’s hard to interpret, but isn’t the whole point of CI/CD that developers don’t start builds explicitly? For example, your example doesn’t mention it. You push to a branch, then wait for the build to finish, but never explicitly start it.
So, it seems they want to allow free use in CI/CD setups. Unfortunately, there are a lot of other ways to implicitly invoke the linker. Your typical IDE may already do that when you click “Run” instead of “Build”. I can easily see a lawyer argue that running make qualifies as explicit invocation, too.
No. And it's very intentional. You're not even legally allowed to run macOS VMs on non Apple hardware.
What's far worse than macOS not being a server OS is the hardware you're forced to contend with. Apple makes no server hardware. You end up with a disgusting hodgepodge of vendors making offerings that are largely redundancy in the way of massive falovers of mac minis. It's very unfortunate and makes self hosting or specifically (hardware or otherwise) needs extremely difficult.
> non-interactive use of the Software that is not explicitly invoked by an individual
...then we get "use of the Software that is interactive or explicitly invoked by an individual".
I would say that running make to run sold to run/test/ship an executable, or clicking "Run" to invoke sold and test the app, or pushing a branch to run CI that runs sold to obtain an executable to run/test/ship, all easily should be considered to be AIU - after all, in all cases it's a person clicking a button (or typing a command), waiting for it to run, and then doing something with the result.
>But honestly, I'm fine with this move. It's still FOSS for FOSS-systems, while support for non-FOSS systems is non-FOSS. The folks who care about free-as-in-freedom won't be affected by this.
I completely agree. If you believe "software should be Free!", then you're going to be using a Linux (or other FOSS) system, not MacOS. On top of that, Apple users are happy to pay through the nose for Apple products, plus apps in the Apple app store. Many studies have shown that app developers make much more money in the Apple app store than in the Google Play store, because Apple users love spending money on stuff, and Android users tend to be much more frugal. Apple users were the ones totally happy to throw away their wired headphones and rush out and buy $150 AirPods when Apple took away their headphone jacks. So this company is smart with this move: make the product a paid product for that group of users that has proven they're happy to spend lots of money on things. If anything, this company might have erred by not pricing it high enough to make it look like a luxury purchase.
Or maybe they are not as rich, since Apple is essentially a filter for "people who are willing to spend 700+ for a phone". Or they have more choices with better free/cheaper applications. Or they are able to pirate.
I don't see how those two things are mutually exclusive.
But yes, it is a filter, which is why business tend to start out on iOS for early revenue numbers, and only port to Android a year later at the earliest. If you start out on Android, you'll inherently have lower revenue numbers, and spending time on your Android app is basically burning money when you're still in your Angel/Series A phases.
Being rich doesn't necessarily mean being stupid with your money; lots of rich people are infamously cheap in fact (the character of Ebeneezer Scrooge wasn't completely made-up after all). Apple phones are very high-priced in terms of features/$ compared to the highest-end Android phones, and many Android phones are in the same price territory (such as the Galaxy series).
In the US, though, there's definitely a perception that Apple is for richer people and Android is for cheapskates.
Isn't compilation mostly linker constrained in realistic scenarios? I mean first compilation time is quite long, but then it's often linker who is to blame for most of the compile time.
It depends. Optimized production builds are dominated by compile times but developer local builds are mostly only compiling a hand full of files but need to link the whole binary (other compilation objects can be reused as they have already been compiled in the past and haven't changed).
Chromium build time after changing a single source file is about a minute completely dominated by link time. And this is with a development component build when most of the code is split into separated DLLs.
> this is a moral outrage because all software should be fr£
Forget that for a moment. Economically speaking, there's tons of free competition and it doesn't have any real problems. That means the market price for a linker is $0. As you point out, people aren't going to pay for a faster one.
The only "moral outrage" here would be if they released experimental code (as they called it) into the gpl version, got people to test out, make prs for it, then yanked it out before it was complete and moved out to the paid version. No clue how it actually went here.
Businesses may be not constrained with the link times, but they for sure are worried with growing executable sizes. And large dev teams rarely reduce the code size, they just keep adding layers and layers of code as the time goes, eventually running beyond the permissible app size on the appstore. Can it solve such growth problem? Many large companies will be "sold" on this idea instantly https://twitter.com/stantwinb/status/1336890442768547845
There's at least one compiler whose developers are complaining about the slow speeds of LLVM's linker. As far as I remember the only thing keeping them from using mold was the absence of a Windows version. Why they didn't sponsor it though, I'm not sure, it looks like Rui would take on some paid work.
> How many businesses are so constrained by link times on Mac […]
Long link times are not specific to OS X / iOS. Large C++ codebases are some of the worst offenders and emit obscene numbers of relocations and DWARF symbols (or similar) into object files that bog linkers down. KDE, Firefox and Chrome browsers instantly come to mind. Rust and GHC generated object files also take a whiiiiiiiile to link[0].
On the businesses being constrainted by the link times subject more specifically. Über posted an article a while back enunciating the shenanigans they have to go through to build their iOS app (the app download at some point measured in a 300Mb+ vicinity): https://www.uber.com/en-GB/blog/how-uber-deals-with-large-io... . From the «Build Times» section of the blog post:
> The default pipeline builds the app in 21 minutes; the new pipeline with no machine outlining takes 53 minutes, which includes about 7 minutes of llvm-link, 14 minutes opt, 11 minutes of llc and 3 minutes of the system linker. One round of outlining takes about 7 minutes in llc, and 2 rounds take 9 minutes. Each additional round adds progressively less extra time, usually under 30 seconds. Overall, 5 rounds of outlining builds in 66 minutes — a 45-minutes addition to the baseline.
So, a default CI/CD build with no outlining heuristics applied spends 10 mins (7 + 3) out of a total of 53 mins in the linker. That is for a single CI/CD run.
And, since at least company has funded the work on fixing relocatable file generation in mold, there is indeed at least some demand:
> GHC (Glasgow Haskell Compiler) in particular uses re-linkable object files as dynamic libraries instead of real .so files, and it didn't work with mold. Now, mold can produce object files that GHC can load. Note that this work was funded by Mercury, so thanks to the company to help us improve the product.
[0] Fun fact: I have measured the memory throughput at the GHC linking time (via LLVM lld); it averages 65Gb/sec, and it can occasionally shoot over 70Gb/sec. So a faster linker still matters.
Why would CI/CD hold up a dev team if it's done asynchronously?
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.
Professional developer here, working with some of the best build systems on the planet–distributed, cached, the whole nine yards. In the past I worked as an iOS engineer for a project which would benefit from mold. You are very wrong about how to produce impact at scale.
When your actual job is dependent on the build completing there’s not a whole lot you can do in the 5-10 minutes it takes to complete. You can skim a bit of email but there isn’t actually much you can do during that time that has lasting impact. I know, because I worked on projects like these on the side: precisely because this time was difficult to schedule stuff into, you’d save hundreds of thousands of dollars per year for each minute you reduced build times. I made a handful of these changes and they were always in longer stretches of slack time, such as when I was waiting for approvals to go through. There’s not much you can do in five minutes but it is very valuable for it to be turned into two minutes.
Are you implying it's a good thing a tool is slow, because it then allows you to show off your degree of professionalism? Or am I misinterpreting your opinion on this matter?
As far as I'm concerned, I'd love faster linkers, compilers, everything. I don't believe longer compile times help me make more money. Are your posts subsidized by time share CPU companies? Or Big Power, by any chance?
@sacnoradhq: what did you the person building the build system in the first place? Or the one that actually builds the runner instances themselves that everybody else leverages?
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.
If I’m developing a feature, I run the newly written unit tests locally. If I have a CI failure, the first step in debugging is to reproduce the failing test locally.
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.
Having a quick edit->build->run iteration time is important. Drop your dogmatic views on what makes a "professional" (hint: it literally just means someone who gets paid to do the work).
Mold doesn't solve any problems for small- or medium-sized projects... there's is little/no advantage.
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.
Anyone who writes C/C++/Rust, like I do, can benefit tremendously from Mold. I use it daily. Each time I hit save and need to run my program, Mold saves me about 10 seconds in linking time. That time adds up quickly, and prevents me from getting distracted.
Lots of developers want to use it, they may just not know about it. A linker is a drop in replacement for another in the general case. I don't know anybody who would refuse a faster toolchain if the end program runs the same.
I know the author of this tool really wants to be able to make a living off this tool, and I fully support their pursuit of this, but I can't help but wonder if doubling down on the strategy of making it harder to use to try out rather than easier is the wrong approach. The project I work on could potentially get a lot of benefit from switching over to mold, and I work at a company that potentially would be able to finance this project at the level they want due to the scale and potential amount of usage internally, but any attempts I've made to try to initiate discussion essentially isn't able to make progress due to the fact that I can't even attempt to make an estimate of how much it would cost (either in aggregate or per user/machine/team/etc.), and due to the fact that all of our builds happen in thoroughly scrutinized non-local environments and I can't just copy the code to a personal machine with mold installed to try out, I also can't offer any concrete numbers about how much time it would save to use it for our builds. It's unfortunate, because I think everyone basically agrees that this would 100% be worth pursuing if we knew for sure that it would be a significant improvement, as build times are a known pain point for our team, but no one with enough authority to actually try to contact and start discussing terms with the developer has enough time to justify spending bandwidth on this when I realistically don't have any concrete evidence that this would provide any benefit at all (and I don't really blame them for this, since I'm essentially just offering a hunch that this would be useful if we could use it).
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.
AGPL does not get triggered by distributing mold produced binaries or using mold. It gets triggered by using it as a service for someone else, for example automated code compilation for someone else.
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.
In the same way, the sold linker is not legal to use except within its license, but this has no bearing on the binaries produced, as those are not derived work of the sold linker. The binaries produced are unrestricted, only using the sold linker in the first place is the issue.
I tried to cover this in my second paragraph, but I'll give it another shot; whether it's legal or not to use internally doesn't really change the political reality that trying to use this internally at most big companies will be an uphill battle that most people aren't going to fight. From a pragmatic perspective, perspective matters even if it's irrational; if anything, the fact that someone holds a perspective that's irrational is even _more_ of an argument that cold reason might not be effective at changing their behavior. This is a thing I've struggled with a lot in various circumstances, and I think it's not an uncommon hurdle for a lot of us in the tech community, but ultimately you have to decide whether you care more about how you make your case or if you care more about whether it succeeds. It's a totally defensible position to take that you shouldn't have to cater to people who have irrational fears about your product and that they should be willing to try it out based on the fact that the risk they worry about isn't real, but if what you really want is to be able to sell the product and have people use it, you won't be happy at the end of the day if that strategy doesn't work. I might be entirely incorrect about what the goals of the author of mold are, but based on what I've read, it sounds like this is basically the situation they're in now. If I'm incorrect, and they're genuinely happier sticking to their strategy even if it costs them the ability to sell the product, then my advice doesn't apply and they can and should ignore it. If they aren't happier this way though, I hope that they either consider a different strategy or that I'm completely wrong about what's stopped it from succeeding so far, because I just don't see the situation changing if there isn't a shift in how it's marketed.
> However, I guess you're right, very few business will care enough to use anything else.
The mold author previously stated that they had several $BigCorp businesses asking about a macOS version and that they were eager about it. I don't have more details other than that (I don't even know which companies), but it seems there is some interest.
I remember reading that something related to function sections wasn’t supported?
If it actually works as an alternative linker option for static linked Haskell builds using ghc on osx I will happily pay for this. But I need more info about the suport surface area they are committing to!
Since some people are down voting my post without given a reason, let me ask this here?
Why should I forgo all the robustness that gnu ld gives me and use an AGPL linker to save some cpu cycle while relying perhaps my most important build component on this thing?
No, thanks. And no amount of downvotes will help that , either.
Honestly, kudos for the author. This seems to be a one man's effort (https://github.com/rui314). He is making a free (as in money and freedom) AGPL product for general purpose usage (linux) and he is selling a particular integration for a particular audience (mac users).
I honestly hope he succeeds in this endeavor. It shows you can do a one-person open source project and still live off of it.
I'm a huge fan of SublimeText the editor, but not a huge fan of SublimeText the company behind it. The balancing act they did was sell licenses that are good for an entire major version (eg SublimeText 2, 3, etc.) that never expire. I'm comfortable enough to pay $50 for a good IDE major version even though I dislike the company's development direction (eg, I'm probably not going to buy SublimeText 4 because of the plugin chaos).
EDIT: "Sublime Text license keys are no longer tied to a single major version, instead they are now valid for all updates within 3 years of purchase" - looks like I'm a pirate then.
79 comments
[ 3.4 ms ] story [ 159 ms ] threadAlso `sold` is a genius name.
If it just works and I need to make sure I shell over the appropriate amount for our usecase it will already be easier.
If I need to pay up front to see how much real world gain we would get I am much likely not to do it. (Looking at you EE graalvm specifically now.)
All software should be free-as-in-freedom, but not nescessarily free-as-in-£; though I acknowledge that the former without the latter is often problematic. Plus, even beyond the "moral should", practically speaking, going non-FOSS this means it gets excluded from GNU/Linux distro packages, which IMO would be a fatal hit for something like this.
But honestly, I'm fine with this move. It's still FOSS for FOSS-systems, while support for non-FOSS systems is non-FOSS. The folks who care about free-as-in-freedom won't be affected by this. And even then, the non-FOSS `sold` is source-available, which covers 3 of the 4 freedoms; and IMO that missing freedom is the least important.
> I still suspect they won't succeed. How many businesses are so constrained by link times on Mac that they're willing to pay to reduce them? (And go through the admin effort of paying for something.)
A reasonable amount of software is "free-as-in-£ for personal use, paid for professional use." Lots of orgs are willing to ask individual devs "are there any dev tools you use that we should be paying for" and are willing to pay the $50/mo for IntelliJ, so $10/mo for `sold` seems to me like it stands a chance? Note that `sold` is still free-as-in-£ for use in CI/CD, and is only paid for individual-developer use.
The relevant part of the EULA [1] states:
> Individuals who use the Software only occasionally, or non-interactive use of the Software that is not explicitly invoked by an individual such as CI/CD (continuous integration/continuous delivery), are not considered Active Interactive-use Users ("AIUs"). No additional fees are required for such uses.
I had to read it multiple times to understand the CI/CD bit. It's not clear to me whether the EULA says that CI/CD is an example of "use that is explicitly invoked by an individual" or if it's an example of "non-interactive use that is not explicitly invoked by an individual" - the wording is unclear to me and can have either of the opposite interpretations.
At my day job, we occasionally test C++ code changes by compiling in a CI/CD system to obtain a container image that we can push into a staging environment. This means we have a develop-compile-test cycle where the "compile" step involves pushing to a merge request branch, waiting for CI/CD to finish, and then running a deploy script to push out the newly-built image for testing. I wonder if this would be considered "Active Interactive-use Use" or not.
[1] https://github.com/bluewhalesystems/sold/blob/main/LICENSE.m...
I agree that it’s hard to interpret, but isn’t the whole point of CI/CD that developers don’t start builds explicitly? For example, your example doesn’t mention it. You push to a branch, then wait for the build to finish, but never explicitly start it.
So, it seems they want to allow free use in CI/CD setups. Unfortunately, there are a lot of other ways to implicitly invoke the linker. Your typical IDE may already do that when you click “Run” instead of “Build”. I can easily see a lawyer argue that running make qualifies as explicit invocation, too.
For better or worse, iOS is not a niche target.
What's far worse than macOS not being a server OS is the hardware you're forced to contend with. Apple makes no server hardware. You end up with a disgusting hodgepodge of vendors making offerings that are largely redundancy in the way of massive falovers of mac minis. It's very unfortunate and makes self hosting or specifically (hardware or otherwise) needs extremely difficult.
> non-interactive use of the Software that is not explicitly invoked by an individual
...then we get "use of the Software that is interactive or explicitly invoked by an individual".
I would say that running make to run sold to run/test/ship an executable, or clicking "Run" to invoke sold and test the app, or pushing a branch to run CI that runs sold to obtain an executable to run/test/ship, all easily should be considered to be AIU - after all, in all cases it's a person clicking a button (or typing a command), waiting for it to run, and then doing something with the result.
I completely agree. If you believe "software should be Free!", then you're going to be using a Linux (or other FOSS) system, not MacOS. On top of that, Apple users are happy to pay through the nose for Apple products, plus apps in the Apple app store. Many studies have shown that app developers make much more money in the Apple app store than in the Google Play store, because Apple users love spending money on stuff, and Android users tend to be much more frugal. Apple users were the ones totally happy to throw away their wired headphones and rush out and buy $150 AirPods when Apple took away their headphone jacks. So this company is smart with this move: make the product a paid product for that group of users that has proven they're happy to spend lots of money on things. If anything, this company might have erred by not pricing it high enough to make it look like a luxury purchase.
Or maybe they are not as rich, since Apple is essentially a filter for "people who are willing to spend 700+ for a phone". Or they have more choices with better free/cheaper applications. Or they are able to pirate.
But yes, it is a filter, which is why business tend to start out on iOS for early revenue numbers, and only port to Android a year later at the earliest. If you start out on Android, you'll inherently have lower revenue numbers, and spending time on your Android app is basically burning money when you're still in your Angel/Series A phases.
In the US, though, there's definitely a perception that Apple is for richer people and Android is for cheapskates.
Forget that for a moment. Economically speaking, there's tons of free competition and it doesn't have any real problems. That means the market price for a linker is $0. As you point out, people aren't going to pay for a faster one.
Long link times are not specific to OS X / iOS. Large C++ codebases are some of the worst offenders and emit obscene numbers of relocations and DWARF symbols (or similar) into object files that bog linkers down. KDE, Firefox and Chrome browsers instantly come to mind. Rust and GHC generated object files also take a whiiiiiiiile to link[0].
On the businesses being constrainted by the link times subject more specifically. Über posted an article a while back enunciating the shenanigans they have to go through to build their iOS app (the app download at some point measured in a 300Mb+ vicinity): https://www.uber.com/en-GB/blog/how-uber-deals-with-large-io... . From the «Build Times» section of the blog post:
> The default pipeline builds the app in 21 minutes; the new pipeline with no machine outlining takes 53 minutes, which includes about 7 minutes of llvm-link, 14 minutes opt, 11 minutes of llc and 3 minutes of the system linker. One round of outlining takes about 7 minutes in llc, and 2 rounds take 9 minutes. Each additional round adds progressively less extra time, usually under 30 seconds. Overall, 5 rounds of outlining builds in 66 minutes — a 45-minutes addition to the baseline.
So, a default CI/CD build with no outlining heuristics applied spends 10 mins (7 + 3) out of a total of 53 mins in the linker. That is for a single CI/CD run.
And, since at least company has funded the work on fixing relocatable file generation in mold, there is indeed at least some demand:
> GHC (Glasgow Haskell Compiler) in particular uses re-linkable object files as dynamic libraries instead of real .so files, and it didn't work with mold. Now, mold can produce object files that GHC can load. Note that this work was funded by Mercury, so thanks to the company to help us improve the product.
[0] Fun fact: I have measured the memory throughput at the GHC linking time (via LLVM lld); it averages 65Gb/sec, and it can occasionally shoot over 70Gb/sec. So a faster linker still matters.
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.
When your actual job is dependent on the build completing there’s not a whole lot you can do in the 5-10 minutes it takes to complete. You can skim a bit of email but there isn’t actually much you can do during that time that has lasting impact. I know, because I worked on projects like these on the side: precisely because this time was difficult to schedule stuff into, you’d save hundreds of thousands of dollars per year for each minute you reduced build times. I made a handful of these changes and they were always in longer stretches of slack time, such as when I was waiting for approvals to go through. There’s not much you can do in five minutes but it is very valuable for it to be turned into two minutes.
As far as I'm concerned, I'd love faster linkers, compilers, everything. I don't believe longer compile times help me make more money. Are your posts subsidized by time share CPU companies? Or Big Power, by any chance?
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:
In the same way, the sold linker is not legal to use except within its license, but this has no bearing on the binaries produced, as those are not derived work of the sold linker. The binaries produced are unrestricted, only using the sold linker in the first place is the issue.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...
"Link fast: Improve build and launch times"
https://developer.apple.com/videos/play/wwdc2022/110362
However, I guess you're right, very few business will care enough to use anything else.
… and I’m developing on macOS, re-linking a large project hundreds of times a day.
The mold author previously stated that they had several $BigCorp businesses asking about a macOS version and that they were eager about it. I don't have more details other than that (I don't even know which companies), but it seems there is some interest.
If it actually works as an alternative linker option for static linked Haskell builds using ghc on osx I will happily pay for this. But I need more info about the suport surface area they are committing to!
[1] https://github.com/rui314/mold/blob/main/docs/design.md
Why should I forgo all the robustness that gnu ld gives me and use an AGPL linker to save some cpu cycle while relying perhaps my most important build component on this thing?
No, thanks. And no amount of downvotes will help that , either.
I honestly hope he succeeds in this endeavor. It shows you can do a one-person open source project and still live off of it.
https://twitter.com/rui314/status/1593464571586830336
See Licensing on https://github.com/rui314/mold/releases/tag/v1.7.0
This instantly kills a lot of goodwill and puts "sold" into "unavailable" rather than "expensive" bucket.
A license for a major version number? And then buy a new license for the next major bump up?
Okay fine.
But a never-ending fire hose of money coming out of my bank account is big nope. I have enough small monthly recurring charges, thanks.
EDIT: "Sublime Text license keys are no longer tied to a single major version, instead they are now valid for all updates within 3 years of purchase" - looks like I'm a pirate then.
Why? This is an altogether better arrangement unless they take over 3 years to release the next major version.