6 ms·

That’s an interesting business direction to attempt — it’s not as if Apple’s linker is lacking in any particularly obvious way.

rafram 4y ago
mold is very, very fast.
- sacnoradhq 4y ago
  Doesn't matter how fast or amazing it is if no one wants to use it.
  - Grimburger 4y ago
    What monetary value would you place on hours of compile time daily holding up your dev team?
    - sacnoradhq 4y ago
      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.
      - terafo 4y ago
        Why do you assume that compilation only happens in CI/CD?
        sacnoradhq 4y ago
        Because professionals don't wait around synchronously for local builds when they can do distributed builds async.
        jraph 4y ago
        Oh yes, they do. Source: I'm a professional dev. 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.
        sacnoradhq 4y ago
        [flagged]
        saagarjha 4y ago
        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.
        eptcyka 4y ago
        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?
        mynameisash 4y ago
        But no true dev would put sugar on his porridge.
      - cylon13 4y ago
        Do you never find yourself interested in the results of a code change you have just made?
        sacnoradhq 4y ago
        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.
        saagarjha 4y ago
        > The primary use case for mold is giant projects with massive executables. Ok, so what’s the point of contention here? Large projects from large companies with lots of money stand to benefit from mold.
        j16sdiz 4y ago
        > Mold doesn't solve any problems for small- or medium-sized projects... there's is little/no advantage. It does. In incremental builds, most of the time are spent in linking, not building.
      - nitsky 4y ago
        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.
    - deleted 4y ago
      [deleted]
  - speed_spread 4y ago
    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.
  - saghm 4y ago
    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.
pjmlp 4y ago
Actually it is, hence why linker improvements tend to come up at WWDC. "Link fast: Improve build and launch times" https://developer.apple.com/videos/play/wwdc2022/110362 https://developer.apple.com/videos/play/wwdc2022/110362 However, I guess you're right, very few business will care enough to use anything else.
- catiopatio 4y ago
  I didn’t notice linker speed before or after those improvements, hence, “non-obvious”. … and I’m developing on macOS, re-linking a large project hundreds of times a day.
- Beltalowda 4y ago
  > 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.
  - pjmlp 4y ago
    Well, I guess he knows better then, hope it works alright for him, after being on the edge of almost giving up.

rafram 4y ago

mold is very, very fast.

sacnoradhq 4y ago
Doesn't matter how fast or amazing it is if no one wants to use it.
- Grimburger 4y ago
  What monetary value would you place on hours of compile time daily holding up your dev team?
  - sacnoradhq 4y ago
    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.
    - terafo 4y ago
      Why do you assume that compilation only happens in CI/CD?
      - sacnoradhq 4y ago
        Because professionals don't wait around synchronously for local builds when they can do distributed builds async.
        jraph 4y ago
        Oh yes, they do. Source: I'm a professional dev. 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.
        sacnoradhq 4y ago
        [flagged]
        saagarjha 4y ago
        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.
        eptcyka 4y ago
        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?
        mynameisash 4y ago
        But no true dev would put sugar on his porridge.
    - cylon13 4y ago
      Do you never find yourself interested in the results of a code change you have just made?
      - sacnoradhq 4y ago
        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.
        saagarjha 4y ago
        > The primary use case for mold is giant projects with massive executables. Ok, so what’s the point of contention here? Large projects from large companies with lots of money stand to benefit from mold.
        j16sdiz 4y ago
        > Mold doesn't solve any problems for small- or medium-sized projects... there's is little/no advantage. It does. In incremental builds, most of the time are spent in linking, not building.
    - nitsky 4y ago
      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.
  - deleted 4y ago
    [deleted]
- speed_spread 4y ago
  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.
- saghm 4y ago
  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.

pjmlp 4y ago

Actually it is, hence why linker improvements tend to come up at WWDC. "Link fast: Improve build and launch times" https://developer.apple.com/videos/play/wwdc2022/110362 https://developer.apple.com/videos/play/wwdc2022/110362 However, I guess you're right, very few business will care enough to use anything else.

catiopatio 4y ago
I didn’t notice linker speed before or after those improvements, hence, “non-obvious”. … and I’m developing on macOS, re-linking a large project hundreds of times a day.
Beltalowda 4y ago
> 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.
- pjmlp 4y ago
  Well, I guess he knows better then, hope it works alright for him, after being on the edge of almost giving up.