Introducing the D Programming Language

[NightmareX1337]

Because @NightmareX1337 is mistaken (or at least not wholly accurate).

static

means static lifetime, which in this case is the same as in C++, but D just has the rule that such variables must be initialized with a constant expression. If you use this in a function, on a variable you modify you will get unexpected results. If you do not plan to modify the variable it is equivalent to making the variable

constexpr

in C++.

I'm not mistaken here. Try to initialize a static variable with a return value of a function in C and you will be suprized.

I dislike a lot of the syntax in D, particularly the syntax for templates. Say what you will about angle bracket syntax in C++, but it is distinct and easily recognizable. I find particularly function template declarations in D are ugly.

This is ironic that you tell me D templates look ugly and keep coding in C++.

D has garbage collection. And you cannot go near it without being contaminated by the radiation unless you are separated by 1 meter wall of concrete in every direction, and I would rather avoid having concrete in my programs.

D gives you fine-grained control over it's garbage collector. In fact, you can totally avoid it and use malloc / free instead. std.experimental.allocator package contains allocator abstractions for different memory management strategies. You can use std.typecons.Unique and std.typecons.RefCounted for deterministic resource management. There are GC independent standard library forks around. D language is a pragmatic tool that becomes what you want it to be. Stop complaining, start experimenting.

Differentiation between value and reference types in the core language. In fact I have never seen a good reason for reference types, but even if such a case exists (which I sure hope it does or it shows a very negative tendency in a lot of popular programming languages) it should not be implemented in the core language, but as a library feature.

I never dealt with value type classes but I guess reference types make things easier for both users and compiler writers.

Lack of experience with D. C++ has a lot of weird quirks, but I have learned what they are and how to avoid them, to a point where I practically never run into them. I do not know about any of the quirks in D and learning about them when I have a perfectly good alternative is not going to happen without another really good incentive, and on top of that I also do not know how to write simple things in D like variadic template value parameters, which is a rather nice thing to know how to do.

This is not a valid argument of not using a language. Of course, I'm more familiar with C# and I can just use it instead but it's more fun to discover new things. There are way less quirks in D than those exist in C++.
Variadic template function can be written as such:

D-Code: void write(Args...)(Args args) if(args.length >0) { writeln(args.length, '\t', args[0]); foreach(i, arg; args) writeln('[', i, ']', typeof(arg).stringof, ' ', arg); }

I see. So I understand things gets implicitly declared for CTFE? I am not sure, this link NX gave is of a forum thread in which the first post links to an issue posted on stack overflow that shows how hideous this can become.

Ohh great. Did I told you how hideous C++ can become?

I don't understand what you mean by that.

I mean there are also other factors one should consider when comparing a language to another. I named Vulkan as an example for an API which came available natively on C and not other languages. Other languages one generally need to wait for wrappers and ports or write them on their own. Also, most of the questions/pitholes of C/C++, if not all, have already been asked at least once on the internet for you to find when you're stumbled. That's probably not true for D however, with which you're to expect a less active community supporting it.

I don't think your example worth discussing (no offense), but I find D community to be surprisingly active. Yes, it's a small community, but really active.