Comment by nanolith
10 months ago
> > 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?
3 replies →