Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> clang's website attempts to demonstrate the superiority of clang by comparing against the error messages from gcc 4.2, a version of gcc that wasn't even the most current when that comparison was published.

This is the latest version available by default on MacOS and FreeBSD (for licensing reasons; subsequent versions are GPLv3), the two operating systems where clang sees most use.



At which point you may as well just point out "clang is maintained; unlike gcc 4.2, which at best will only receive back-ported compilation and security fixes, clang is under active development" ;P. You don't even need to motivate "better": it just needs to be "all least sort of as good". In the end, the only legit reason for this change is licensing, and any references to technical superiority between clang and gcc as a whole are red herrings at best and disingenuous at worst.


Apple certainly has technical reasons for using clang; good luck getting the degree of integration XCode has with clang with GCC (the plugin system added as a response to clang existing would help, but would not be sufficient in itself). BSD has less clear ones, though I would hope that other C/C++ IDEs will start adding similar levels of integration.

Ultimately, clang offers a way forward without having to adopt GPLv3 software, and besides that offers considerable benefit to people making development tools. Its big selling point has never really been speed; that it can generally keep up is enough.

EDIT: You could certainly also make the claim that Clang's far faster compilation is a technical feature, especially for C++ programmers. There are actually people who use clang for development, for the fast compilation and static analysis, then build for production with a newish GCC.


My comment complains about the error handling comparison and then makes assertions about the "only legit reason for this change" <- "this change", of course, being the one to FreeBSD. I am not quite certain how issues Apple runs into with Xcode are relevant (and talking about hypothetical future IDEs, which certainly would not be FreeBSD-specific and which would treat clang as any other library to depend on, doesn't make the motivation any more clear to me).

To address your second paragraphs, I am responding to a comment (yours) justifying why clang should spend time on their website making comparisons against gcc 4.2, a stance you defend by stating that that is the version that people are using instead of clang. Now, in your response to my defense against that point, you are bringing up legitimate technical benefits of clang against all versions of gcc...

...but I would never, nor have I so far in this thread, complained that those benefits didn't exist; I especially haven't claimed that those version-independent architecture benefits shouldn't be mentioned on their website. My complaint, remember, is that there are specific nebulous benefits (error output) being touted against gcc 4.2 as the "most notable" (according to the SO answer being discussed) technical be benefit of this project.

That specific benefit only exists because of a licensing decision, as gcc after-4.2 does not have error output this bad (not do I believe it did in 4.3 trunk at the time that website was published). The honest reason, if "error output" is important, as to why clang is better than gcc for FreeBSD is thereby "licensing", as if licensing weren't the real reason that benefit evaporates: it is no better than just pointing out that gcc 4.2 is unmaintained.

However, and again, you are more than welcome to be happy or excited about any other real benefits, either to other parties or the ones in question, but your comments in this context are anticipating complaints I haven't made and in fact is aggressively arguing with me over something I don't even disagree with: it is as if you see anyone complaining about clang and presume "they must just be a hater" and knee-jerk your way through a muscle-memory argument over "why clang is better" (something I have no strong opinion about).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: