Why not D?

[sanxiyn]

As far as I can tell, Carbon's goals are pretty much compatible with D, as Walter Bright pointed out as soon as Carbon was posted to Hacker News.

I suspect this must have been discussed, so it would be nice to have "Why not D" entry in FAQ, in addition to existing "Why not Rust" entry. I must not be the only one to be curious.

Thanks!

[doug-moen]

Parts of the D standard library require a garbage collector. Carbon and C++ do not require GC, and do not normally use a GC. That seems like a big difference. It's going to be an important issue for anyone who does not want a GC in their runtime. In D, you can compile with @nogc, and get compile errors when your code or its dependencies uses something that requires GC. This seems worse than not having to worry about the issue at all.

Clearly, if you want GC then D is a better choice than Carbon. But that's not who Carbon is being designed for.

[niutech]

What if D's stdlib didn't require GC in the future? What's the rationale for Carbon apart from GC?

[OlaFosheimGrostad]

D will not add the ability to instantiate C++ templates in D code. D has spent the last year adding the ability to compile C with the D compiler. Carbon has a completely different design focus.

[doug-moen]

Carbon can directly include C++ header files. D can't do this, and it is not a goal. Quote:

Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end to D. Anecdotal evidence suggests that writing such is a minimum of a 10 man-year project, essentially making a D compiler with such capability unimplementable.

[vladimmi]

D definitely can do that with tools like dpp

[mrMiiao]

D definitely can do that with tools like dpp

Not really. dpp is really cool but it doesn't fully support C, and a fortiori C++.

[skyline131313]

[chandlerc]

Generic criticisms of another language are not on-topic here. Where other languages work for folks, we encourage using them.

Discussion here should focus on the unique problem space of Carbon -- how we can or can't build a viable successor language for C++. Generic concerns with a language aren't relevant. The up-thread comment about C++-interop provided by D is the only in-scope thing.

I also want to very specifically point out that insults aren't valid in any circumstance, please avoid calling things "toys" or otherwise being dismissive towards them.

I've removed the content of this comment given the above, but am leaving this as a reminder to the community.

[vladimmi]

I would change that to "why not a fork/improvements of D?". D has unmatched nice syntax base and templates/CTFE system but its developers seem to have 0 interest in making it usable beyond the system programming.

Reusing things that already work perfect and reimplementing questionable parts seems to be better option than making it from scratch and being worse. Especially when D already had prototypes in that field - dpp for direct includes of C/C++, calypso as mixed C/C++/D compiler on top of Clang and LDC for seamless integration of all.

[lexi-nadia]

To paraphrase @chandlerc:

Generic criticisms of another language or their developers are not on-topic here. Where other languages work for folks, we encourage using them.

Discussion here should focus on the unique problem space of Carbon -- how we can or can't build a viable successor language for C++. Generic concerns with a language aren't relevant. The up-thread comment about C++-interop provided by D is the only in-scope thing.

Also, see https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#why-not-fork-c. While that question is about forking C++, the same rationale applies for forking D or any other language.

[lexi-nadia]

I've filed #1875 to add an FAQ entry for this.