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".
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.
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.
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.
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.
By separating the two. If there’s no Cargo.lock, resolution needs to be done, and the result is written out to the lock file. If the lock file is there, then you don’t need to re-run resolution, you just read out the result from the file.
The latency you’re arguing over is probably more to do with rustup selecting the right cargo and exec-ing that than dependency resolution. It’s heavier weight than it should be due to history reasons.
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.
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.
I'm going to recommend everyone ignore this poster, just don't reply to them.
They're not going to accept anything other than "yes, you're right jerf" and any attempt to do so is going to be met with squawking about motte and bailey fallacy because they believe internally they've found the perfect defense.
If you don't think it's helpful to engage, put your money where your mouth is, and don't engage, i.e. stop posting.
Note I'm saying if you don't think it's helpful to engage. I don't have any objections to you posting. It just makes you look a bit silly to keep engaging while claiming that engaging isn't worthwhile.
I'm really not sure what relevance you think that link has--I'm not seeing any particular intolerance happening here. Disagreement != intolerance.
If you're going to put words in my mouth, then there's no need for me to respond any further.
If you are genuinely curious about build systems in any language, I can certainly help you. But, if this is the "Cargo is the best vs all others" debate, kindly count me out. I don't care. Cargo is fine if you're doing Rust work. If you're using other languages or platforms, there are plenty of excellent alternatives.
This sort of Rust proselytizing -- on an article about C of all things -- is why so many perceive the Rust community as being toxic. You might think you're helping to spread the glory of Rust, but that's not how you are coming across.
Note that I'm not even comparing the merits between the two languages. If you like Rust, write software in Rust. If you like building your Rust projects in Cargo, have at it.
> But, if this is the "Cargo is the best vs all others" debate...
It isn't. It's certainly better than any C build systems, but I'm aware of a few other similar build systems (just not for C).
> ...kindly count me out. I don't care.
Only you have the power to stop posting. And if you did, it would make your claim that you don't care a lot more convincing.
> If you're using other languages or platforms, there are plenty of excellent alternatives.
True! But C isn't one of those languages.
And let's be real, that's really why you're mad. It isn't that I'm bringing up Rust that's making you mad, it's that I'm criticizing C.
C isn't perfect and it's not the best at everything. And that's fine! It's great for what it is. But what it isn't is a modern language with modern tooling. And that's a real downside to consider when choosing a language to write a project in.
That's not the only consideration, and there are a lot of reasons why I, myself, would choose C for a new project (not the least of being that I'm a lot better at C than at Rust).
> This sort of Rust proselytizing -- on an article about C of all things -- is why so many perceive the Rust community as being toxic. You might think you're helping to spread the glory of Rust, but that's not how you are coming across.
I'm not particularly concerned with how I represent the Rust community. I don't even view myself as part of the Rust community (yet). If anything, I have a lot more claim to being a member of the C community than of the Rust community, as I've written orders of magnitude more C code than Rust code.
> > But, if this is the "Cargo is the best vs all others" debate...
> It isn't.
You could've fooled me with how uncharitable you are being here by blowing comments way out of proportion.
> Only you have the power to stop posting.
Full context: "But, if this is the "Cargo is the best vs all others" debate, kindly count me out."
Using ellipses and quote mining to make your opponent look foolish is the lowest form of sophistry and against HN policy. There isn't a "debate" to "win" here. So, why go to this sort of trouble over nothing?
> > If you're using other languages or platforms, there are plenty of excellent alternatives.
> True! But C isn't one of those languages.
I fail to see what C has to do with the choice of build tools. C isn't a build tool; it's a language.
> And let's be real, that's really why you're mad.
Who is mad? Literally, I replied with a comment about build tools. You keep trying to have the debate you want here by inserting words in people's mouths. It's disingenuous.
> C isn't perfect and it's not the best at everything.
No one. NO ONE, has made any claims even remotely like that. Yet another silly strawman for the debate you desperately want to have here.
> But what it isn't is a modern language with modern tooling.
Actually, there is excellent modern tooling for C. There are proof assistants and model checkers. It's possible to do similar things in modern C as in Rust or other languages, from proving the absence of UB to proving memory safety features. But, seriously, no one is having this debate, so it's silly. We were talking about build tools...
> I'm not particularly concerned with how I represent the Rust community.
Good, because these silly "debates" -- over a build tool that has somehow mushroomed into a C vs Rust debate in only your head and no one else's -- might seem cool to you, but are counter-productive.
> as I've written orders of magnitude more C code than Rust code.
And yet, you've never done any reading about modern build tools or package systems with C support. That's a mighty shame.
By the way, did you know that you can build C/C++ projects using Cargo? Yeah. Me neither. Huh.
> Full context: "But, if this is the "Cargo is the best vs all others" debate, kindly count me out."
Okay, then my response to the full context is:
This isn't the "Cargo is the best vs all others" debate.
If you wish to be counted out, you can stop posting at any time.
You'll note that this is basically what I said to your post when I was "taking it out of context", with the exception that I also responded to some context you decided to leave out when you quoted yourself.
> Using ellipses and quote mining to make your opponent look foolish is the lowest form of sophistry and against HN policy.
I split up your comments when I quoted them to make it clearer what I was responding to.
> I fail to see what C has to do with the choice of build tools.
You are definitely smart enough to figure that out.
The author of the original article seems to see the connection, given they titled their article "How to Structure C Projects" and then went on to write a bunch about a build system.
> > C isn't perfect and it's not the best at everything.
> No one. NO ONE, has made any claims even remotely like that.
Sure, nobody is foolish enough to make such a claim so obviously. But if a person responds to any criticism of C with vitriol, one begins to think that person is invested in a belief that C is perfect.
> Actually, there is excellent modern tooling for C. There are proof assistants and model checkers. It's possible to do similar things in modern C as in Rust or other languages, from proving the absence of UB to proving memory safety features.
And I'm sure these modern tools are easy enough to use that everyone uses them, given their obvious benefits, right? Have you even used a proof assistant?
To be clear what point I'm making: these tools are amazing, feats of engineering, but they're not really viable for most C projects. Using a proof assistant is far harder than you're giving it credit for, enough so that I very much doubt that you've one to prove things about C programs. If you have, you're much smarter than me, because I've tried, and proving anything non-trivial was beyond what I could do with reasonable effort.
> By the way, did you know that you can build C/C++ projects using Cargo? Yeah. Me neither. Huh.
If I go into a average Rust project, and run "cargo run", Cargo will build the project, and the resulting binary will run.
If I go into a random C project, and run "cargo run", that won't happen.
And in fact, there is not a tool in existence where I can go into a random C project and run that tool, and it will build the C project. "make" is about as close as you can get to that, and in most C projects that simple four letter command is glossing over a whole lot of work that went into producing the Makefile.
I'll remind you of when you said, "I fail to see what C has to do with the choice of build tools."
> > I fail to see what C has to do with the choice of build tools.
> You are definitely smart enough to figure that out.
Clearly not, because the features you enumerate with respect to Cargo aren't unique to Rust or non-existent in C. They are simply build tool features. If you learn what these features are called, you can search for them in other tools, assuming that's not too much "effort" for you.
> But if a person responds to any criticism of C with vitriol,
So far, the only people in this thread replying with vitriol are you and jerf. Believe it or not, I was trying to be helpful, and somehow you keep trying to rope me into a dumb Rust debate that NO ONE CARES ABOUT.
> Have you even used a proof assistant?
Only daily. But, let's keep those unfounded assumptions coming...
> To be clear what point I'm making: these tools are amazing, feats of engineering, but they're not really viable for most C projects.
Ah, but CBMC is completely viable for any C project, and proof assistants are very much on the way toward viability for general adoption right now. I should know, because that's kind of an area of specialty for me.
> If I go into a average Rust project, and run "cargo run", Cargo will build the project, and the resulting binary will run.
> If I go into a random C project, and run "cargo run", that won't happen.
Now we get to the crux of your issue. You want a zero-configuration build tool. They exist for practically every language and platform. Search for that phrase and be enlightened. But, just like cargo, you'll still need to add configuration for customization (or pass it on the command-line).
> And in fact, there is not a tool in existence where I can go into a random C project...
Note that this is a proper use of ellipses. See above: it's called a zero-configuration build tool. Your ignorance of their existence should not be construed as evidence of cargo's uniqueness.
> I'll remind you of when you said, "I fail to see what C has to do with the choice of build tools."
The reminder is rather silly, as we've just exposed that you haven't put in the "effort" to understand the tools that exist for C, despite having over a million lines of C under your belt. :-)
> Clearly not, because the features you enumerate with respect to Cargo aren't unique to Rust or non-existent in C.
You literally said that one of the features I want from a build system isn't possible in C. You said, "None of them _could_ be the standard, because C is used on thousands of different platforms."
Having a standard build system is extremely useful.
> > Have you even used a proof assistant?
> Only daily. But, let's keep those unfounded assumptions coming...
I won't say I haven't made some incorrect assumptions in this conversation, but in this case, I assumed nothing; I asked a question.
This is the sort of thing I'm referring to when I say that you respond with vitriol, by the way--this sarcasm wasn't necessary to make your point.
> > To be clear what point I'm making: these tools are amazing, feats of engineering, but they're not really viable for most C projects.
> Ah, but CBMC is completely viable for any C project, and proof assistants are very much on the way toward viability for general adoption right now. I should know, because that's kind of an area of specialty for me.
Well, I genuinely hope you succeed, and maybe you will in the near future, but from the perspective of someone trying to use proof assistants, I'm telling you, you haven't succeeded yet. Maybe it's because the best proof assistant isn't publicized enough for me to have found out about them, maybe it's because the problem is intractably hard, I'm not sure.
I also suspect you're a bit overstating the viability of CBMC, but it's been a few years since I looked at the CBMC tools available so I'll grant the possibility there have been strides taken since then, and if this Rust thing doesn't work out maybe I'll take another look.
> See above: it's called a zero-configuration build tool. Your ignorance of their existence should not be construed as evidence of cargo's uniqueness.
Cargo is a zero configuration build tool, but it's not just a zero configuration build tool.
Notably, zero-configuration build tools don't do what I described--you condescendingly (vitriolically?) assumed I haven't tried zero-configuration build tools for C. I have, and they do not do what I described--you have not at all responded to what I said.
There does not exist a tool that you can go into an average C codebase and run it and expect reasonable results, because C codebases aren't all built with the same assumptions--for a zero-configuration tool to work reliably you have to build from the beginning with the same configuration assumptions as that tool. And even if you do that, the "zero configuration" falls apart as soon as you introduce a dependency, because they likely didn't make the same assumptions as the ZC build tool.
The benefit to having a build system like Cargo that is built in tandem with the language and everyone writing the language uses it, which means that everyone using the language writes it with the same assumptions as the zero-configuration build system. This means when you stumble upon a random project in that language, you already know how to build it without reading a lot of documentation.
And as an aside: "go build" works for Go just as well as "cargo build" does for Rust, for the same reasons. You're the only one making this a Rust vs. C debate. I wasn't going to respond to that because I'm trying (perhaps unsuccessfully) to focus on the technology discussion, but I'm a bit tired of having to skip past you (vitriolically) ranting about how toxic Rustaceans are attacking C every other paragraph.
> The reminder is rather silly, as we've just exposed that you haven't put in the "effort" to understand the tools that exist for C.
I won't claim to know every build tool that exists for C, but I will say that I've looked into plenty in my time.
As for your snidely (vitriolically?) disparaging my not putting effort into learning tools: I actually put a lot of effort into learning tools, but I insist that effort not be wasted. There are a lot of reasons learning a new tool is not a good idea. Will it be maintained 5 years from now, or am I learning a skill that will soon be useless? Is it widely used, or will I only be able to use it in niche situations? Is it stable?
> Sarcasm and ill tone is fine when you use it, but not when I respond to it in kind.
Not at all. Use all the sarcasm you want; I'm a big boy and I can handle it.
And I'm not denying I used some unnecessary sarcasm myself.
But you said, "So far, the only people in this thread replying with vitriol are you and jerf." And I just wanted to make you aware that that's not quite correct.
You're not the innocent victim in this conversation that you think you are.
> But if a person responds to any criticism of C with vitriol, one begins to think that person is invested in a belief that C is perfect.
That was before I started responding in kind.
> You're not the innocent victim in this conversation that you think you are.
Oh, I was. You and jerf certainly started the rude behavior. Expecting me to sit back and take it, and then pouncing on me for "vitriol" for responding in kind is... wait for it... SEALIONING.
Push the envelope, then call the other out for pushing back, as if you're the injured party.
Either way, this is far outside of acceptable behavior on HN. I'm disengaging for good this time. I offered you useful advice. You tried to turn this into a silly Rust debate that no one wanted. Then, you act like the aggrieved party because no one wants it.
> 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.
My goal is to be able to build my project with as little effort as possible. "Effort" includes evaluating different tools and reading their documentation.
When selecting a language to write a new project in, the history of the language isn't something I care about.
Didn't you just say that you didn't want to read about any other build system, as that would involve effort? Uh... okay.
> The reason you aren't naming one is that they obviously _aren't_ similar in ways that matter.
Or, as I said previously, I'm not interested in endorsing build tools I haven't used, because I'm not in the market for a cargo clone. They exist. Plenty of folks I know are happy with one or another. Build tools are not difficult to write. As with the article, if you don't like existing build tools, spend an afternoon writing your own. It's a little graph theory and job management.
> Didn't you just say that you didn't want to read about any other build system, as that would involve effort?
No, I did not say that, and you also know that.
> Or, as I said previously, I'm not interested in endorsing build tools I haven't used, because I'm not in the market for a cargo clone. They exist.
If you've not used them, then your confidence that they are equivalent to Cargo comes from where?
> Build tools are not difficult to write. As with the article, if you don't like existing build tools, spend an afternoon writing your own. It's a little graph theory and job management.
I'm the author of the Fur programming language, which does need a package management system, so I will be doing this at some point. But I very much doubt that it will be as easy as you claim.
> > Didn't you just say that you didn't want to read about any other build system, as that would involve effort?
> No, I did not say that, and you also know that.
and
> My goal is to be able to build my project with as little effort as possible. "Effort" includes evaluating different tools and reading their documentation.
Apparently, I don't know that, or I'm being trolled. What even is knowing something when folks contradict themselves two replies in?
> If you've not used them, then your confidence that they are equivalent to Cargo comes from where?
The endorsements of others who have used the tools. But, I'm starting to suspect that you wouldn't consider any endorsement of any tool other than cargo as valid...
> which does need a package management system, so I will be doing this at some point. But I very much doubt that it will be as easy as you claim.
Note that I said "build tool". A package management system is a hair more complicated. You'll need a week instead of an afternoon.
> What even is knowing something when folks contradict themselves two replies in?
You quoted two bits and are claiming they are contradictory, but they aren't.
I said, "My goal is to be able to build my project with as little effort as possible. "Effort" includes evaluating different tools and reading their documentation."
That's not "I don't want to read about any other build systems besides Cargo."
I'm happy to read about other build systems. I would be extremely happy if I found one as easy as Cargo for C, but I'm quite confident that doesn't exist.
But it took me all of 3 minutes to learn how to do everything I need to do with Cargo, and it was simple enough that I have it committed to memory and never have to read it again. I don't want waste time reading about build systems that are immediately obviously harder to use and don't do anything more, because that is a complete and utter waste of time.
And I say "You know that" because it's not some puzzle if you were looking to understand what I say instead of attack it.
> Note that I said "build tool". A package management system is a hair more complicated. You'll need a week instead of an afternoon.
> 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.
> 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?
> ...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.
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".
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.
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.
that's only true if you believe dependency resolution is free.
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.
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.
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.
the real world, where nothing means something.
Cargo does not do dependency resolution on every build.
how does a dependency management system ensure the dependencies are there without doing dependency resolution?
By separating the two. If there’s no Cargo.lock, resolution needs to be done, and the result is written out to the lock file. If the lock file is there, then you don’t need to re-run resolution, you just read out the result from the file.
The latency you’re arguing over is probably more to do with rustup selecting the right cargo and exec-ing that than dependency resolution. It’s heavier weight than it should be due to history reasons.
dealing with the Cargo.lock is a part of the dependency resolution.
Isn’t it the price of the LLVM backend? That would make it a rustc implementation price.
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.
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.
I'm going to recommend everyone ignore this poster, just don't reply to them.
They're not going to accept anything other than "yes, you're right jerf" and any attempt to do so is going to be met with squawking about motte and bailey fallacy because they believe internally they've found the perfect defense.
it's not worth engaging.
So basically you recommend everyone ignore them because they disagree with you?
It's strange that you think this post is you "not engaging".
oh snap, you totally got me...
https://en.wikipedia.org/wiki/Paradox_of_tolerance
If you don't think it's helpful to engage, put your money where your mouth is, and don't engage, i.e. stop posting.
Note I'm saying if you don't think it's helpful to engage. I don't have any objections to you posting. It just makes you look a bit silly to keep engaging while claiming that engaging isn't worthwhile.
I'm really not sure what relevance you think that link has--I'm not seeing any particular intolerance happening here. Disagreement != intolerance.
I'm not surprised you don't understand the point.
If you're going to put words in my mouth, then there's no need for me to respond any further.
If you are genuinely curious about build systems in any language, I can certainly help you. But, if this is the "Cargo is the best vs all others" debate, kindly count me out. I don't care. Cargo is fine if you're doing Rust work. If you're using other languages or platforms, there are plenty of excellent alternatives.
This sort of Rust proselytizing -- on an article about C of all things -- is why so many perceive the Rust community as being toxic. You might think you're helping to spread the glory of Rust, but that's not how you are coming across.
Note that I'm not even comparing the merits between the two languages. If you like Rust, write software in Rust. If you like building your Rust projects in Cargo, have at it.
> But, if this is the "Cargo is the best vs all others" debate...
It isn't. It's certainly better than any C build systems, but I'm aware of a few other similar build systems (just not for C).
> ...kindly count me out. I don't care.
Only you have the power to stop posting. And if you did, it would make your claim that you don't care a lot more convincing.
> If you're using other languages or platforms, there are plenty of excellent alternatives.
True! But C isn't one of those languages.
And let's be real, that's really why you're mad. It isn't that I'm bringing up Rust that's making you mad, it's that I'm criticizing C.
C isn't perfect and it's not the best at everything. And that's fine! It's great for what it is. But what it isn't is a modern language with modern tooling. And that's a real downside to consider when choosing a language to write a project in.
That's not the only consideration, and there are a lot of reasons why I, myself, would choose C for a new project (not the least of being that I'm a lot better at C than at Rust).
> This sort of Rust proselytizing -- on an article about C of all things -- is why so many perceive the Rust community as being toxic. You might think you're helping to spread the glory of Rust, but that's not how you are coming across.
I'm not particularly concerned with how I represent the Rust community. I don't even view myself as part of the Rust community (yet). If anything, I have a lot more claim to being a member of the C community than of the Rust community, as I've written orders of magnitude more C code than Rust code.
> > But, if this is the "Cargo is the best vs all others" debate...
> It isn't.
You could've fooled me with how uncharitable you are being here by blowing comments way out of proportion.
> Only you have the power to stop posting.
Full context: "But, if this is the "Cargo is the best vs all others" debate, kindly count me out."
Using ellipses and quote mining to make your opponent look foolish is the lowest form of sophistry and against HN policy. There isn't a "debate" to "win" here. So, why go to this sort of trouble over nothing?
> > If you're using other languages or platforms, there are plenty of excellent alternatives.
> True! But C isn't one of those languages.
I fail to see what C has to do with the choice of build tools. C isn't a build tool; it's a language.
> And let's be real, that's really why you're mad.
Who is mad? Literally, I replied with a comment about build tools. You keep trying to have the debate you want here by inserting words in people's mouths. It's disingenuous.
> C isn't perfect and it's not the best at everything.
No one. NO ONE, has made any claims even remotely like that. Yet another silly strawman for the debate you desperately want to have here.
> But what it isn't is a modern language with modern tooling.
Actually, there is excellent modern tooling for C. There are proof assistants and model checkers. It's possible to do similar things in modern C as in Rust or other languages, from proving the absence of UB to proving memory safety features. But, seriously, no one is having this debate, so it's silly. We were talking about build tools...
> I'm not particularly concerned with how I represent the Rust community.
Good, because these silly "debates" -- over a build tool that has somehow mushroomed into a C vs Rust debate in only your head and no one else's -- might seem cool to you, but are counter-productive.
> as I've written orders of magnitude more C code than Rust code.
And yet, you've never done any reading about modern build tools or package systems with C support. That's a mighty shame.
By the way, did you know that you can build C/C++ projects using Cargo? Yeah. Me neither. Huh.
> Full context: "But, if this is the "Cargo is the best vs all others" debate, kindly count me out."
Okay, then my response to the full context is:
This isn't the "Cargo is the best vs all others" debate.
If you wish to be counted out, you can stop posting at any time.
You'll note that this is basically what I said to your post when I was "taking it out of context", with the exception that I also responded to some context you decided to leave out when you quoted yourself.
> Using ellipses and quote mining to make your opponent look foolish is the lowest form of sophistry and against HN policy.
I split up your comments when I quoted them to make it clearer what I was responding to.
> I fail to see what C has to do with the choice of build tools.
You are definitely smart enough to figure that out.
The author of the original article seems to see the connection, given they titled their article "How to Structure C Projects" and then went on to write a bunch about a build system.
> > C isn't perfect and it's not the best at everything.
> No one. NO ONE, has made any claims even remotely like that.
Sure, nobody is foolish enough to make such a claim so obviously. But if a person responds to any criticism of C with vitriol, one begins to think that person is invested in a belief that C is perfect.
> Actually, there is excellent modern tooling for C. There are proof assistants and model checkers. It's possible to do similar things in modern C as in Rust or other languages, from proving the absence of UB to proving memory safety features.
And I'm sure these modern tools are easy enough to use that everyone uses them, given their obvious benefits, right? Have you even used a proof assistant?
To be clear what point I'm making: these tools are amazing, feats of engineering, but they're not really viable for most C projects. Using a proof assistant is far harder than you're giving it credit for, enough so that I very much doubt that you've one to prove things about C programs. If you have, you're much smarter than me, because I've tried, and proving anything non-trivial was beyond what I could do with reasonable effort.
> By the way, did you know that you can build C/C++ projects using Cargo? Yeah. Me neither. Huh.
If I go into a average Rust project, and run "cargo run", Cargo will build the project, and the resulting binary will run.
If I go into a random C project, and run "cargo run", that won't happen.
And in fact, there is not a tool in existence where I can go into a random C project and run that tool, and it will build the C project. "make" is about as close as you can get to that, and in most C projects that simple four letter command is glossing over a whole lot of work that went into producing the Makefile.
I'll remind you of when you said, "I fail to see what C has to do with the choice of build tools."
> > I fail to see what C has to do with the choice of build tools.
> You are definitely smart enough to figure that out.
Clearly not, because the features you enumerate with respect to Cargo aren't unique to Rust or non-existent in C. They are simply build tool features. If you learn what these features are called, you can search for them in other tools, assuming that's not too much "effort" for you.
> But if a person responds to any criticism of C with vitriol,
So far, the only people in this thread replying with vitriol are you and jerf. Believe it or not, I was trying to be helpful, and somehow you keep trying to rope me into a dumb Rust debate that NO ONE CARES ABOUT.
> Have you even used a proof assistant?
Only daily. But, let's keep those unfounded assumptions coming...
> To be clear what point I'm making: these tools are amazing, feats of engineering, but they're not really viable for most C projects.
Ah, but CBMC is completely viable for any C project, and proof assistants are very much on the way toward viability for general adoption right now. I should know, because that's kind of an area of specialty for me.
> If I go into a average Rust project, and run "cargo run", Cargo will build the project, and the resulting binary will run.
> If I go into a random C project, and run "cargo run", that won't happen.
Now we get to the crux of your issue. You want a zero-configuration build tool. They exist for practically every language and platform. Search for that phrase and be enlightened. But, just like cargo, you'll still need to add configuration for customization (or pass it on the command-line).
> And in fact, there is not a tool in existence where I can go into a random C project...
Note that this is a proper use of ellipses. See above: it's called a zero-configuration build tool. Your ignorance of their existence should not be construed as evidence of cargo's uniqueness.
> I'll remind you of when you said, "I fail to see what C has to do with the choice of build tools."
The reminder is rather silly, as we've just exposed that you haven't put in the "effort" to understand the tools that exist for C, despite having over a million lines of C under your belt. :-)
> Clearly not, because the features you enumerate with respect to Cargo aren't unique to Rust or non-existent in C.
You literally said that one of the features I want from a build system isn't possible in C. You said, "None of them _could_ be the standard, because C is used on thousands of different platforms."
Having a standard build system is extremely useful.
> > Have you even used a proof assistant?
> Only daily. But, let's keep those unfounded assumptions coming...
I won't say I haven't made some incorrect assumptions in this conversation, but in this case, I assumed nothing; I asked a question.
This is the sort of thing I'm referring to when I say that you respond with vitriol, by the way--this sarcasm wasn't necessary to make your point.
> > To be clear what point I'm making: these tools are amazing, feats of engineering, but they're not really viable for most C projects.
> Ah, but CBMC is completely viable for any C project, and proof assistants are very much on the way toward viability for general adoption right now. I should know, because that's kind of an area of specialty for me.
Well, I genuinely hope you succeed, and maybe you will in the near future, but from the perspective of someone trying to use proof assistants, I'm telling you, you haven't succeeded yet. Maybe it's because the best proof assistant isn't publicized enough for me to have found out about them, maybe it's because the problem is intractably hard, I'm not sure.
I also suspect you're a bit overstating the viability of CBMC, but it's been a few years since I looked at the CBMC tools available so I'll grant the possibility there have been strides taken since then, and if this Rust thing doesn't work out maybe I'll take another look.
> See above: it's called a zero-configuration build tool. Your ignorance of their existence should not be construed as evidence of cargo's uniqueness.
Cargo is a zero configuration build tool, but it's not just a zero configuration build tool.
Notably, zero-configuration build tools don't do what I described--you condescendingly (vitriolically?) assumed I haven't tried zero-configuration build tools for C. I have, and they do not do what I described--you have not at all responded to what I said.
There does not exist a tool that you can go into an average C codebase and run it and expect reasonable results, because C codebases aren't all built with the same assumptions--for a zero-configuration tool to work reliably you have to build from the beginning with the same configuration assumptions as that tool. And even if you do that, the "zero configuration" falls apart as soon as you introduce a dependency, because they likely didn't make the same assumptions as the ZC build tool.
The benefit to having a build system like Cargo that is built in tandem with the language and everyone writing the language uses it, which means that everyone using the language writes it with the same assumptions as the zero-configuration build system. This means when you stumble upon a random project in that language, you already know how to build it without reading a lot of documentation.
And as an aside: "go build" works for Go just as well as "cargo build" does for Rust, for the same reasons. You're the only one making this a Rust vs. C debate. I wasn't going to respond to that because I'm trying (perhaps unsuccessfully) to focus on the technology discussion, but I'm a bit tired of having to skip past you (vitriolically) ranting about how toxic Rustaceans are attacking C every other paragraph.
> The reminder is rather silly, as we've just exposed that you haven't put in the "effort" to understand the tools that exist for C.
I won't claim to know every build tool that exists for C, but I will say that I've looked into plenty in my time.
As for your snidely (vitriolically?) disparaging my not putting effort into learning tools: I actually put a lot of effort into learning tools, but I insist that effort not be wasted. There are a lot of reasons learning a new tool is not a good idea. Will it be maintained 5 years from now, or am I learning a skill that will soon be useless? Is it widely used, or will I only be able to use it in niche situations? Is it stable?
> > > Have you even used a proof assistant?
> > Only daily. But, let's keep those unfounded assumptions coming...
and
> This is the sort of thing I'm referring to when I say that you respond with vitriol, by the way--this sarcasm wasn't necessary to make your point.
I see. Sarcasm and ill tone is fine when you use it, but not when I respond to it in kind. I'm not interested in Sealioning. Goodbye.
Post whatever replies you want and "win" this pointless "debate". I don't care to play this stupid game. Good day.
> Sarcasm and ill tone is fine when you use it, but not when I respond to it in kind.
Not at all. Use all the sarcasm you want; I'm a big boy and I can handle it.
And I'm not denying I used some unnecessary sarcasm myself.
But you said, "So far, the only people in this thread replying with vitriol are you and jerf." And I just wanted to make you aware that that's not quite correct.
You're not the innocent victim in this conversation that you think you are.
Sorry... had to come back for one last reply.
> But if a person responds to any criticism of C with vitriol, one begins to think that person is invested in a belief that C is perfect.
That was before I started responding in kind.
> You're not the innocent victim in this conversation that you think you are.
Oh, I was. You and jerf certainly started the rude behavior. Expecting me to sit back and take it, and then pouncing on me for "vitriol" for responding in kind is... wait for it... SEALIONING.
https://en.wikipedia.org/wiki/Sealioning
Push the envelope, then call the other out for pushing back, as if you're the injured party.
Either way, this is far outside of acceptable behavior on HN. I'm disengaging for good this time. I offered you useful advice. You tried to turn this into a silly Rust debate that no one wanted. Then, you act like the aggrieved party because no one wants it.
> 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.
My goal is to be able to build my project with as little effort as possible. "Effort" includes evaluating different tools and reading their documentation.
When selecting a language to write a new project in, the history of the language isn't something I care about.
If your goal is "I want to use Cargo and nothing else because that would require effort to learn to type a different command", then use Cargo.
But, there are similar build and package systems for C. Cargo is nothing special.
> If your goal is "I want to use Cargo and nothing else because that would require effort to learn to type a different command", then use Cargo.
That's not my goal, and you know that.
> But, there are similar build and package systems for C.
The reason you aren't naming one is that they obviously aren't similar in ways that matter.
> That's not my goal, and you know that.
Didn't you just say that you didn't want to read about any other build system, as that would involve effort? Uh... okay.
> The reason you aren't naming one is that they obviously _aren't_ similar in ways that matter.
Or, as I said previously, I'm not interested in endorsing build tools I haven't used, because I'm not in the market for a cargo clone. They exist. Plenty of folks I know are happy with one or another. Build tools are not difficult to write. As with the article, if you don't like existing build tools, spend an afternoon writing your own. It's a little graph theory and job management.
> Didn't you just say that you didn't want to read about any other build system, as that would involve effort?
No, I did not say that, and you also know that.
> Or, as I said previously, I'm not interested in endorsing build tools I haven't used, because I'm not in the market for a cargo clone. They exist.
If you've not used them, then your confidence that they are equivalent to Cargo comes from where?
> Build tools are not difficult to write. As with the article, if you don't like existing build tools, spend an afternoon writing your own. It's a little graph theory and job management.
I'm the author of the Fur programming language, which does need a package management system, so I will be doing this at some point. But I very much doubt that it will be as easy as you claim.
> > Didn't you just say that you didn't want to read about any other build system, as that would involve effort?
> No, I did not say that, and you also know that.
and
> My goal is to be able to build my project with as little effort as possible. "Effort" includes evaluating different tools and reading their documentation.
Apparently, I don't know that, or I'm being trolled. What even is knowing something when folks contradict themselves two replies in?
> If you've not used them, then your confidence that they are equivalent to Cargo comes from where?
The endorsements of others who have used the tools. But, I'm starting to suspect that you wouldn't consider any endorsement of any tool other than cargo as valid...
> which does need a package management system, so I will be doing this at some point. But I very much doubt that it will be as easy as you claim.
Note that I said "build tool". A package management system is a hair more complicated. You'll need a week instead of an afternoon.
> What even is knowing something when folks contradict themselves two replies in?
You quoted two bits and are claiming they are contradictory, but they aren't.
I said, "My goal is to be able to build my project with as little effort as possible. "Effort" includes evaluating different tools and reading their documentation."
That's not "I don't want to read about any other build systems besides Cargo."
I'm happy to read about other build systems. I would be extremely happy if I found one as easy as Cargo for C, but I'm quite confident that doesn't exist.
But it took me all of 3 minutes to learn how to do everything I need to do with Cargo, and it was simple enough that I have it committed to memory and never have to read it again. I don't want waste time reading about build systems that are immediately obviously harder to use and don't do anything more, because that is a complete and utter waste of time.
And I say "You know that" because it's not some puzzle if you were looking to understand what I say instead of attack it.
> Note that I said "build tool". A package management system is a hair more complicated. You'll need a week instead of an afternoon.
Your confidence in me is charming.
> 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.
Thank you for that demonstration of the motte & bailey argument.
thank you for being a dismissive jackass.
> 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?
> 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.
> 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?
> ...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.