The D Language Front-End Is Trying Now To Get Into GCC 9

[Michael_S]

I'm no D expert, but last time I checked, the "really cool features" in D have been later implemented in C++. All the constexpr stuff, lambdas, template extensions, static asserts, and so on. The builtin unit test block doesn't replace a full unit test suite. D might be a better C++, but if a project requires C++ level code generation, it could just pick C++ these days. Go and Rust solve different problems, but D is just C++ "on steroids".

How does git uses GCC? I think like many other C software it can be compiled with different C compilers. GCC isn't dying but D was never really alive. Unlike Rust and Go, it failed to gain any significant mindshare and there is no reason to believe it will. Adding D frontend to GCC is really strange, why not to add a dozen other frontends for languages with similar popularity?

Go had Google's backing and Rust didn't start as an official Mozilla project but it was adopted by it and has theirs. D has its own merits on par with those two, and it's silly to say, "Let it die since it doesn't have a hundred million dollar charity or multi-billion dollar corporation promoting it!"

Even if all that D ever does is explore features that end up getting used to improve C++, that's worthwhile. And as far as I can tell C++11, C++14, etc... have borrowed more from D than they have from any other languages, so you can't even say that Go or Rust (or Scala or whatever) do a good enough job feeding ideas into the C++ standards committee.

And as far as I know there are things in D that C++ still hasn't borrowed or matched.
For one, D has the 'immutable' keyword that goes further than 'const' in C++. It has very fast compile times for both incremental compilation and build-the-world. One of the original design goals of 'Go' was fast compile times, and the last I read a comparison D still compiles faster. D ditches the preprocessor in favor of compile-time expression compilation, so you can write cross-platform code or selectively enable features like you would in C or C++ without any runtime overhead as in C or C++ but the code to do it is much simpler. I also find the D expression for templates and generics much easier to read than in C++, and I think most people new to both languages would also find D much easier to read and write. The language still has value.

As for GCC, I'm just responding to the assertion by GunpowaderGuy that GCC is 'virtually abandoned' for anything. It's very much alive. I realize git or the Linux kernel or anything else compiled with GCC could be compiled with LLVM, the only exception would be projects that make heavy use of some GCC-only extensions. The point is that many projects still do default to using GCC, which means it's really far from being almost abandoned.

[caligula]

Even if all that D ever does is explore features that end up getting used to improve C++, that's worthwhile. And as far as I can tell C++11, C++14, etc... have borrowed more from D than they have from any other languages, so you can't even say that Go or Rust (or Scala or whatever) do a good enough job feeding ideas into the C++ standards committee.

The truth is, D authors are active in the C++ community. The C++ standards committee doesn't adopt features from D. C++ standardization process was awfully stuck few years ago. I've seen at least few ideas discussed in the C++ community before D adopted them. Of course D might implement them differently (cleaner syntax), but the ideas were already there. The process of adopting is a lot faster for a one man team than for a committee with industrial partners (IBM, Oracle etc.)

It has very fast compile times for both incremental compilation and build-the-world. One of the original design goals of 'Go' was fast compile times, and the last I read a comparison D still compiles faster.

That's probably mostly a feature of that particular implementation. You can make a fast or slow compiler. There's now zapcc for C/C++.

D ditches the preprocessor in favor of compile-time expression compilation, so you can write cross-platform code or selectively enable features like you would in C or C++ without any runtime overhead as in C or C++ but the code to do it is much simpler.

C++ is also in the process of adopting a module system that does not use pre-processor (maybe C++20 or C++23). This cuts down most of the time wasted reparsing the headers.

The language still has value.

The way I see it is that C++ is catching up pretty well. D has some niche features not included in C++ yet, but the industy doesn't seem to agree on their usefulness. For example contract programming has long been available for Java via AspectJ but very few care. Eiffel is practically dead. Contracts don't work well with threads (they can introduce new deadlocks, for instance). I'd be willing to bet on property based testing instead.

Even if all that D ever does is explore features that end up getting used to improve C++, that's worthwhile

Are there any new features in D introduced during the last 10 years (post 2.0)?

[Michael_S]

The truth is, D authors are active in the C++ community. The C++ standards committee doesn't adopt features from D. C++ standardization process was awfully stuck few years ago. I've seen at least few ideas discussed in the C++ community before D adopted them. Of course D might implement them differently (cleaner syntax), but the ideas were already there. The process of adopting is a lot faster for a one man team than for a committee with industrial partners (IBM, Oracle etc.)

I think we're mostly agreed. I think the D leads (Bright and Alexandrescu) use D as a playground for features so that they have the best background before proposing ideas or reacting to proposals by others for C++.

That's probably mostly a feature of that particular implementation. You can make a fast or slow compiler. There's now zapcc for C/C++.


C++ is also in the process of adopting a module system that does not use pre-processor (maybe C++20 or C++23). This cuts down most of the time wasted reparsing the headers.

I think these two things are related. My understanding is that the C/C++ preprocessors execute in something like quadratic time, as processing each file causes more work processing subsequent files. By ditching that, D (or Go, or Rust) are inherently faster to compile and C++ can't catch up, at least for large projects, until their module system is in place.

The way I see it is that C++ is catching up pretty well. D has some niche features not included in C++ yet, but the industy doesn't seem to agree on their usefulness. For example contract programming has long been available for Java via AspectJ but very few care. Eiffel is practically dead. Contracts don't work well with threads (they can introduce new deadlocks, for instance). I'd be willing to bet on property based testing instead.

I'm not sold on contract programming either. But I think bringing Java up is useful because I see Groovy, Scala, Kotlin, etc... serving the same niche for Java. Those three languages are far more popular than D but still each far, far less popular than Java. Even if all they do is drag Java forward, it's still worthwhile. Java 11 is not an especially pleasant language to use - I work with Java, I don't love it - but Java 11 is much nicer than java 7.

Are there any new features in D introduced during the last 10 years (post 2.0)?

Good question. I don't know. To be fair, it had a pretty good feature set 10 years ago.

[caligula]

I think these two things are related. My understanding is that the C/C++ preprocessors execute in something like quadratic time, as processing each file causes more work processing subsequent files. By ditching that, D (or Go, or Rust) are inherently faster to compile and C++ can't catch up, at least for large projects, until their module system is in place.

There are also other things to consider. The linker model has a significant effect on time complexity. C/C++ use a dumb model where you just need to assume that a symbol appears somewhere in the process. If you wanted to optimize this further, the linker could work more hand in hand with the semantic info available earlier. This is especially true when doing a full compilation. You can also build really fast but unmaintainable parsers which provide less useful error messages. A fast compiler is good for building systems, but less practical when doing development. I think zapcc style software solve both problems.

Java 11 is not an especially pleasant language to use - I work with Java, I don't love it - but Java 11 is much nicer than java 7.

I'm surprised that anyone uses Java 11. Hasn't it even been released yet?

Good question. I don't know. To be fair, it had a pretty good feature set 10 years ago.

That's certainly true. I studied D when 2.0 appeared. It seemed quite promising, but I got more distracted with Nim and Rust instead. The core idea in D 2.0 is intriguing, but it was plagued by numerous compiler bugs and immature implementations. All the other tools like the build tool were more or less toys. Now, the ecosystem might be more mature, but it cost them over 10 years to get there. Meanwhile, between 7-11 Java got a rather large list of new features (compared to its previous progress), C++11,14, and 17 are pretty impressive. Rust and Nim. There's also Swift, Scala, Scala Dotty, Kotlin, Go.. lots of promising languages. Even PHP has improved quite a lot. It's not like D is bad. It's just that competition is tight.

[pal666]

I don't think what is left of your natural lifespan is long enough to actually wait that out.

how long is enough for its backing organization to port their one browser to rust? more than ten years was enough to port little part

[pal666]

The truth is, D authors are active in the C++ community.

yes.

The C++ standards committee doesn't adopt features from D

it does. for example, "static if" was pitched by alexandrescu, it became "if constexpr". this does not mean c++ adopts only features from d

C++ is also in the process of adopting a module system that does not use pre-processor (maybe C++20 or C++23). This cuts down most of the time wasted reparsing the headers.

your wording is bad. module system does not "use" even compiler parser, module is at least preparsed. but it can export macros for example.

The way I see it is that C++ is catching up pretty well. D has some niche features not included in C++ yet, but the industy doesn't seem to agree on their usefulness. For example contract programming has long been available for Java via AspectJ but very few care. Eiffel is practically dead. Contracts don't work well with threads (they can introduce new deadlocks, for instance). I'd be willing to bet on property based testing instead.

contracts is largest feature adopted by c++20 so far. contracts are assert on steroids, they complement testing. and they affect code generation (they give information to compiler)

[pal666]

My understanding is that the C/C++ preprocessors execute in something like quadratic time, as processing each file causes more work processing subsequent files.

no. time does not matter. template instantiation in any template heavy code takes orders of magnitude more time. and (fast)code generation also takes orders of magnitude more time. the issue with preprocessor is that it is not c++, it is just some dumb text replacement which knows nothing about your program.

I'm not sold on contract programming either.

do you use asserts in your code?

[profoundWHALE]

I messed around with D way back before even version 1. It was a good idea and fun but suffered from a poor compiler environment. DMD just didn't cut it and gcc produced faster code. It took so long to start getting decent backends that I gave up. By the time they had something I didn't care any more because new C and C++ standards were revitalizing them and scripting languages were performing better than ever.

There was a major rewrite for version 2 (which is this version I think) which brought it up to speed with C and C++.

[Michael_S]

no. time does not matter. template instantiation in any template heavy code takes orders of magnitude more time. and (fast)code generation also takes orders of magnitude more time. the issue with preprocessor is that it is not c++, it is just some dumb text replacement which knows nothing about your program.

Thanks. I knew that optimization is a slower process, but my understanding of most C++ project development cycles is that the engineers use quick compiles most of the time and only the optimize compiles as they get closer to release and do release testing. I did not know that template instantiation was slow.

do you use asserts in your code?

In most of my public methods (in Java terms) yes, I use lots of if-checks on the inputs and return values. I either log a warning or throw an exception based on unexpected results.

The part I'm not sold on is separate language features to handle those mechanisms. I'm willing to be convinced.

[linner]

There was a major rewrite for version 2 (which is this version I think) which brought it up to speed with C and C++.

Yes but like I said, by the time that came out I didn't care any more and had moved on as I think most people did. It didn't gain traction because of mistakes like that and it died. Death is death and it will never be able to recover.

If you want to win a low-level language war it's not enough to just add features. You have to perform better than what you're trying to displace. That is a monumental, nearly impossible, task. Interesting note: I do I lot of data mining and for some pure math stuff LuaJIT actually performs better than hand-coded C. A freaking scripting language. Go figure, but I use it when it makes sense and gives me an advantage.