Comment by nanolith
10 months ago
> > 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.
1 reply →