C++11 & The Long-Term Viability Of GCC Is Questioned

[liam]

So, why can't gcc go into the garage for two years?

[Ericg]

So, why can't gcc go into the garage for two years?

In the same time it'll be in the garage, LLVM/Clang will move miles and miles ahead in performance, features, quality, speed. When gcc came out it would be in the exact same spot LLVM/Clang was...two years prior.

Also the odds of developers leaving it to rot would exponentially go up if they told the world "No new features! No new releases! For two years!" People would get bored, give up, lose hope, and just let gcc die.

[ryao]

In the same time it'll be in the garage, LLVM/Clang will move miles and miles ahead in performance, features, quality, speed. When gcc came out it would be in the exact same spot LLVM/Clang was...two years prior.

Also the odds of developers leaving it to rot would exponentially go up if they told the world "No new features! No new releases! For two years!" People would get bored, give up, lose hope, and just let gcc die.

Source code cannot actually die unless everyone deletes it. Otherwise, it remains dormant.

[Ericg]

Source code cannot actually die unless everyone deletes it. Otherwise, it remains dormant.

The spirit of it dies, the same way the developers on the mailing list talk about-- people stop caring, people stop contributing, ergo...project dies. Code is there, sure, but if it would ever be brought back it wouldn't be the same GCC anymore.

[nickblack]

great article. there was a lot of wisdom distilled into that last quoted paragraph.

[XorEaxEax]

In the same time it'll be in the garage, LLVM/Clang will move miles and miles ahead in performance, features, quality, speed. When gcc came out it would be in the exact same spot LLVM/Clang was...two years prior.

The reason they can't put it in the garage for two years is because so much open source infrastructure depends on it, not only to exist as it is now with bug fixes, but to progress with cpu architecture support, language support, standards support, platform support etc.

Clang/LLVM only supports a subset of the huge hardware/software ecosystem which relies on GCC, so yes they will need to do changes 'on the road', as they've always done. Obviously LLVM and later Clang had the advantage of having nothing be dependent on them during large parts of their development (in large thanks to GCC, LLVM used GCC as it's frontend for most of it's existance), that is a luxury GCC doesn't have.

[XorEaxEax]

As far as I know, Apple open sources stuff on their website and the FreeBSD developers take what they want. xlocale is a good example of this.

And other companies open source tons of code which projects can pick up and use, that is not incorporating something as EricG implied.

Anyway, discussion of the GPL's compatibility with licenses Apple uses really has no place in a discussion of Apple code in FreeBSD. FreeBSD's base system has software under a variety of licenses, including the GPL.

I mentioned GPL and Apple's licence incompability since they are both copy-left. As for FreeBSD's base system, they are (for ideological reasons) purging their base system of GPL licenced code. https://wiki.freebsd.org/GPLinBase

[Pawlerson]

GPL vs. BSD licence wars... i think

It's not about wars, but about being sane. Nobody sane will work with BSD project, so MS and Apple can take his work.

[Pawlerson]

I think LLVM/Clang will be okay. , Apple incorporates many of its advancements back to FreeBSD, as does Netflix. Mostly because maintaining patches out-of-tree that have to be re-applied and tweaked after every rebase is hardwork that can be severely fscked over by upstream. Better to have your changes in upstream if for no better reason than to remove the maintenance burden from yourself.

Like what advancements? The same like their own clang/llvm tree? Stop kidding.

[Pawlerson]

In the same time it'll be in the garage, LLVM/Clang will move miles and miles ahead in performance, features, quality, speed. When gcc came out it would be in the exact same spot LLVM/Clang was...two years prior.

Also the odds of developers leaving it to rot would exponentially go up if they told the world "No new features! No new releases! For two years!" People would get bored, give up, lose hope, and just let gcc die.

Time will tell, because for now it's miles behind GCC. It can't even compile Linux, so it's nearly meaningless.