5 ms·

It is true that C does not have a single tool enforced by the language platform. But, there is plenty of excellent documentation available for using build and

It is true that C does not have a single tool enforced by the language platform. But, there is plenty of excellent documentation available for using build and packaging tools of your choice to work similarly to Cargo.

jerf 3y ago
In practice this comes off as a rather motte and bailey argument. "There's plenty of ways to make building C as easy as Cargo." OK, show me. "Well, you use this and do this and this." OK, that didn't work because of $THIS_REASON. "Oh that's easy to fix you just do this thing." {Repeat several times.} OK, I guess it's working now, but there's no way that was as easy as cargo. "What are you talking about, it was a series of easy steps that only involved reading dozens of pages of docs, a couple of not-quite-current-but-close-to-accurate Stack Overflow posts, upgrading to the correct version of the build tool, and directly posting on a couple of mailing lists!" To be honest, the moment I have to evaluate a dozen tools, pick one, and use it, even if that tool does manage to be "$TOOL build" and literally nothing else which I don't think is anywhere near something people can count on in the C world, it has already proved to be harder than "cargo build".
- norir 3y ago
  There is a price to easy. In my experience, cargo build times tend to be soulkillingly long. But I don't like waiting more than a few hundred ms for incremental builds. So for me, cargo build is actually harder than make to attain an enjoyable build system. Make is annoying but Makefile issues are found quickly and easily when running `find . | entr -c make` and saving the source file often.
  - alpaca128 3y ago
    Build times have nothing to do with cargo but with the language itself. They're not the "price to easy", it's the price of the static compiler checks.
    - PH95VuimJjqBqy 3y ago
      that's only true if you believe dependency resolution is free.
      - alpaca128 3y ago
        I have never witnessed cargo being delayed from that by a noteworthy amount of time. I just tried it, on my PC it takes cargo 0.3 seconds to start compiling the first of 309 dependencies in a clean Bevy repo. The entire compilation takes 31 seconds, and that's the best case with lots of multithreading and all packages already downloaded. That's close enough to "free" for me.
        PH95VuimJjqBqy 3y ago
        doesn't really matter. You said "nothing to do with" and I said "is not free". 1/3 of a second for a build that has already cached all dependencies means I was correct that it's not free and you were being dismissive when you said it had nothing to do with build times. If you want to argue that it's a minimal amount of time then argue that instead of what you've been arguing.
        alpaca128 3y ago
        I was of course talking about usage in the real world, which is the thing that matters in the end. Harping on the precise meaning of words like that is pointless.
        PH95VuimJjqBqy 3y ago
        the real world, where nothing means something.
      - steveklabnik 3y ago
        Cargo does not do dependency resolution on every build.
- nanolith 3y ago
  First, I did not say anywhere in my reply, "as easy as Cargo". I said "similar to Cargo." Huge difference. C has been around for over 50 years. It predates many of the modern "everything including the kitchen sink" style of language platforms. It has spread across so many platforms and uses that a Cargo like integration is not going to happen. But, this does not mean that build, package, and install tools don't exist. If you want me to provide you with a single tool to rule them all, well, that's impossible for the reasons I listed above. But, depending on which platforms you care about and which features you want, there are plenty of existing tools. If your goalpost is "change C to be like Rust and have a single build tool", then that's impossible. If your goalpost is "find me a tool that does X, Y, and Z", then there that is certainly possible. There are Cargo clones for C/C++ that work just fine.
  - jerf 3y ago
    While less aggressively "motte & bailey" then the sibling reply from PH95VuimJjqBqy, you basically proved my point rather than disproving it. You can't name a single tool that is as easy as cargo. I know that's because if you do there will be a dozen replies from users of that tool going "Oh, my, no it was quite difficult to set up, ultimately didn't work for us, and we had to abandon it for this other tool." I do not understand the mindset that believes that if you explain why a problem is hard, it is somehow no longer hard, or somehow it no longer "counts". Yes. C is a sprawling multi-decade monster that never started out with a good build tool because it was just too early in history for that to be the sort of concern it is now. I certainly wouldn't dream of claiming there aren't reasons C is complicated to build, even ones that are generally good when you consider the entire history of the project. The world would not be better off if we had somehow waited for C to be perfect before using it, because it is precisely the act of using C that has taught us the ways to improve other languages. I credit the platform for that, I do not deduct points. However, none of that changes the fact that it is a bear to build anything non-trivial in C, and the simple act of reading a list of your tool options is literally already harder than "cargo build". I basically don't believe by assertion that there are tools that can solve this with just a relatively dainty (by C standards) little declarative file and a single command execution. I'm sure they have a "happy path" that looks like that but as soon as I leave it it'll explode in complexity, and I'm basically guaranteed to leave it at some point for any non-trivial project.
- PH95VuimJjqBqy 3y ago
  > To be honest, the moment I have to evaluate a dozen tools, pick one, and use it, even if that tool does manage to be "$TOOL build" and literally nothing else which I don't think is anywhere near something people can count on in the C world, it has already proved to be harder than "cargo build". C will build and run in places rust can't. so I should argue C is better because in my chosen metric (diversity of platforms) it wins.
  - jerf 3y ago
    Thank you for that demonstration of the motte & bailey argument.
    - PH95VuimJjqBqy 3y ago
      thank you for being a dismissive jackass.
kerkeslager 3y ago
> But, there is plenty of excellent documentation available for using build and packaging tools of your choice to work similarly to Cargo. Sure, and there's plenty of documentation for Cargo too. Or at least I assume there is, but I've never had reason to read it. Do you see the problem with what you're saying?
- nanolith 3y ago
  > Do you see the problem with what you're saying? No, I don't. At some point, you read documentation, or a tutorial, or example code to use Cargo. These exist for other build and package systems, some of which are clones of Cargo. If you want a white glove experience (e.g. cargo new), such systems exist as well for C. Cargo is nothing new.
  - kerkeslager 3y ago
    > At some point, you read documentation, or a tutorial, or example code to use Cargo. ...and the point you're pretending you don't understand, is that the parts I needed were simple enough that I now have it memorized. > These exist for other build and package systems, some of which are clones of Cargo. These exist... but you're not going to even mention any, because you're aware that they aren't equivalent. They don't ship with your C compiler, they don't work for every C project without configuration, etc. I'm open to the possibility that there are better C build tools than the ones I've been using, but they literally cannot be as easy as Cargo because they're hampered by supporting decades of legacy features (and mistakes) of C, the fact that none of them are the standard, etc. And look, no hate on C. It's done its job for decades and if we're measuring by the problems that have been solved in a language, it's arguably the best language in existence. I've certainly chosen it for a lot of my own projects. But do you really think it's perfect? Are you really unwilling to admit that there is anything newer languages do better?
    - nanolith 3y ago
      > ...and the point you're pretending you don't understand... You're making some very interesting assumptions about what I'm thinking here. > These exist... but you're not going to even mention any, because you're aware that they aren't equivalent. Again, you're assigning motives to me based on unfounded assumptions. Actually, I haven't mentioned any because I have no reason to endorse any of them. Not because they are inferior, but because I'm not in the market for a cargo clone. If you were interested in learning more, Google is your friend. If not, well, I'm not here to have some silly debate about how Rust and Cargo are superior to everything ever invented. I don't care. > but they literally cannot be as easy as Cargo because they're hampered by supporting decades of legacy features New tools are opinionated. They choose features commonly used in modern software. > the fact that none of them are _the_ standard None of them _could_ be the standard, because C is used on thousands of different platforms. > But do you really think it's _perfect_? No one, anywhere in this thread, has made this argument or anything approaching this argument. No language is perfect. > Are you really unwilling to admit that there is _anything_ newer languages do better? That's another bizarre strawman. No one on this thread has made claims remotely approaching this. You claimed that you were switching projects to Rust because you don't like C build systems. Taking your comment charitably, I replied that there are build and package tools for C that are literal clones of Cargo. But, now you're making assumptions about my motivations for pointing out this in the comment section of an article about C development and building strawman arguments. Why? I'm not getting sucked into a Rust debate. I don't care. You like Rust? Use it. You like Cargo? Go for it. But, if the reason why you are using either is because you can't find a similar tool for C development, then I recommend doing the reading. The amount of reading required to switch to a new build tool is significantly less than the amount of work required to port even a medium complexity C project to Rust. Of course, if you're looking for an excuse to use Rust, you don't need to use build tools as that excuse. Just write code in Rust. Debating this is silly.

jerf 3y ago

In practice this comes off as a rather motte and bailey argument. "There's plenty of ways to make building C as easy as Cargo." OK, show me. "Well, you use this and do this and this." OK, that didn't work because of $THIS_REASON. "Oh that's easy to fix you just do this thing." {Repeat several times.} OK, I guess it's working now, but there's no way that was as easy as cargo. "What are you talking about, it was a series of easy steps that only involved reading dozens of pages of docs, a couple of not-quite-current-but-close-to-accurate Stack Overflow posts, upgrading to the correct version of the build tool, and directly posting on a couple of mailing lists!" To be honest, the moment I have to evaluate a dozen tools, pick one, and use it, even if that tool does manage to be "$TOOL build" and literally nothing else which I don't think is anywhere near something people can count on in the C world, it has already proved to be harder than "cargo build".

norir 3y ago
There is a price to easy. In my experience, cargo build times tend to be soulkillingly long. But I don't like waiting more than a few hundred ms for incremental builds. So for me, cargo build is actually harder than make to attain an enjoyable build system. Make is annoying but Makefile issues are found quickly and easily when running `find . | entr -c make` and saving the source file often.
- alpaca128 3y ago
  Build times have nothing to do with cargo but with the language itself. They're not the "price to easy", it's the price of the static compiler checks.
  - PH95VuimJjqBqy 3y ago
    that's only true if you believe dependency resolution is free.
    - alpaca128 3y ago
      I have never witnessed cargo being delayed from that by a noteworthy amount of time. I just tried it, on my PC it takes cargo 0.3 seconds to start compiling the first of 309 dependencies in a clean Bevy repo. The entire compilation takes 31 seconds, and that's the best case with lots of multithreading and all packages already downloaded. That's close enough to "free" for me.
      - PH95VuimJjqBqy 3y ago
        doesn't really matter. You said "nothing to do with" and I said "is not free". 1/3 of a second for a build that has already cached all dependencies means I was correct that it's not free and you were being dismissive when you said it had nothing to do with build times. If you want to argue that it's a minimal amount of time then argue that instead of what you've been arguing.
        alpaca128 3y ago
        I was of course talking about usage in the real world, which is the thing that matters in the end. Harping on the precise meaning of words like that is pointless.
        PH95VuimJjqBqy 3y ago
        the real world, where nothing means something.
    - steveklabnik 3y ago
      Cargo does not do dependency resolution on every build.
nanolith 3y ago
First, I did not say anywhere in my reply, "as easy as Cargo". I said "similar to Cargo." Huge difference. C has been around for over 50 years. It predates many of the modern "everything including the kitchen sink" style of language platforms. It has spread across so many platforms and uses that a Cargo like integration is not going to happen. But, this does not mean that build, package, and install tools don't exist. If you want me to provide you with a single tool to rule them all, well, that's impossible for the reasons I listed above. But, depending on which platforms you care about and which features you want, there are plenty of existing tools. If your goalpost is "change C to be like Rust and have a single build tool", then that's impossible. If your goalpost is "find me a tool that does X, Y, and Z", then there that is certainly possible. There are Cargo clones for C/C++ that work just fine.
- jerf 3y ago
  While less aggressively "motte & bailey" then the sibling reply from PH95VuimJjqBqy, you basically proved my point rather than disproving it. You can't name a single tool that is as easy as cargo. I know that's because if you do there will be a dozen replies from users of that tool going "Oh, my, no it was quite difficult to set up, ultimately didn't work for us, and we had to abandon it for this other tool." I do not understand the mindset that believes that if you explain why a problem is hard, it is somehow no longer hard, or somehow it no longer "counts". Yes. C is a sprawling multi-decade monster that never started out with a good build tool because it was just too early in history for that to be the sort of concern it is now. I certainly wouldn't dream of claiming there aren't reasons C is complicated to build, even ones that are generally good when you consider the entire history of the project. The world would not be better off if we had somehow waited for C to be perfect before using it, because it is precisely the act of using C that has taught us the ways to improve other languages. I credit the platform for that, I do not deduct points. However, none of that changes the fact that it is a bear to build anything non-trivial in C, and the simple act of reading a list of your tool options is literally already harder than "cargo build". I basically don't believe by assertion that there are tools that can solve this with just a relatively dainty (by C standards) little declarative file and a single command execution. I'm sure they have a "happy path" that looks like that but as soon as I leave it it'll explode in complexity, and I'm basically guaranteed to leave it at some point for any non-trivial project.
PH95VuimJjqBqy 3y ago
> To be honest, the moment I have to evaluate a dozen tools, pick one, and use it, even if that tool does manage to be "$TOOL build" and literally nothing else which I don't think is anywhere near something people can count on in the C world, it has already proved to be harder than "cargo build". C will build and run in places rust can't. so I should argue C is better because in my chosen metric (diversity of platforms) it wins.
- jerf 3y ago
  Thank you for that demonstration of the motte & bailey argument.
  - PH95VuimJjqBqy 3y ago
    thank you for being a dismissive jackass.

kerkeslager 3y ago

> But, there is plenty of excellent documentation available for using build and packaging tools of your choice to work similarly to Cargo. Sure, and there's plenty of documentation for Cargo too. Or at least I assume there is, but I've never had reason to read it. Do you see the problem with what you're saying?

nanolith 3y ago
> Do you see the problem with what you're saying? No, I don't. At some point, you read documentation, or a tutorial, or example code to use Cargo. These exist for other build and package systems, some of which are clones of Cargo. If you want a white glove experience (e.g. cargo new), such systems exist as well for C. Cargo is nothing new.
- kerkeslager 3y ago
  > At some point, you read documentation, or a tutorial, or example code to use Cargo. ...and the point you're pretending you don't understand, is that the parts I needed were simple enough that I now have it memorized. > These exist for other build and package systems, some of which are clones of Cargo. These exist... but you're not going to even mention any, because you're aware that they aren't equivalent. They don't ship with your C compiler, they don't work for every C project without configuration, etc. I'm open to the possibility that there are better C build tools than the ones I've been using, but they literally cannot be as easy as Cargo because they're hampered by supporting decades of legacy features (and mistakes) of C, the fact that none of them are the standard, etc. And look, no hate on C. It's done its job for decades and if we're measuring by the problems that have been solved in a language, it's arguably the best language in existence. I've certainly chosen it for a lot of my own projects. But do you really think it's perfect? Are you really unwilling to admit that there is anything newer languages do better?
  - nanolith 3y ago
    > ...and the point you're pretending you don't understand... You're making some very interesting assumptions about what I'm thinking here. > These exist... but you're not going to even mention any, because you're aware that they aren't equivalent. Again, you're assigning motives to me based on unfounded assumptions. Actually, I haven't mentioned any because I have no reason to endorse any of them. Not because they are inferior, but because I'm not in the market for a cargo clone. If you were interested in learning more, Google is your friend. If not, well, I'm not here to have some silly debate about how Rust and Cargo are superior to everything ever invented. I don't care. > but they literally cannot be as easy as Cargo because they're hampered by supporting decades of legacy features New tools are opinionated. They choose features commonly used in modern software. > the fact that none of them are _the_ standard None of them _could_ be the standard, because C is used on thousands of different platforms. > But do you really think it's _perfect_? No one, anywhere in this thread, has made this argument or anything approaching this argument. No language is perfect. > Are you really unwilling to admit that there is _anything_ newer languages do better? That's another bizarre strawman. No one on this thread has made claims remotely approaching this. You claimed that you were switching projects to Rust because you don't like C build systems. Taking your comment charitably, I replied that there are build and package tools for C that are literal clones of Cargo. But, now you're making assumptions about my motivations for pointing out this in the comment section of an article about C development and building strawman arguments. Why? I'm not getting sucked into a Rust debate. I don't care. You like Rust? Use it. You like Cargo? Go for it. But, if the reason why you are using either is because you can't find a similar tool for C development, then I recommend doing the reading. The amount of reading required to switch to a new build tool is significantly less than the amount of work required to port even a medium complexity C project to Rust. Of course, if you're looking for an excuse to use Rust, you don't need to use build tools as that excuse. Just write code in Rust. Debating this is silly.