Anybody using language 'D'?

Why isn't it more popular?

+47  A: 

My wild guess is corporate money.

D's creators DigitalMars, aren't really big players in the corporate world in this day and age.

Its target audience was originally Java and/or C++ programmers.

But on the one hand the problem is most 8 to 5 Java programmers won't invest in something like D unless there it is an order from the top, and the people on top, don't know about D, because it's not mentioned in corporate circles. Instead Microsoft has been pushing C#, which targets the same audience but has a big corporate name.

On the other hand C++ programmers are hardcore, myself included, and although we recognize D would reduce the masochism from our lives, we're hooked on pain :) Although to be honest, I keep looking forward to D, just haven't had a chance to use it.

Robert Gould
+1: Likewise looking forward to D; got a pet project to build in it to see how it works.
Adam Hawes
In the Top 10 of languages you can find Python, Perl, Ruby and JavaScript, non of which have corporate backing.
As Robert hinted at, a big difference between D and those languages is who they're meant to appeal to. Matz never intended for Ruby to be the new C++.
Indeed Matz intended Ruby to be the new Perl/Python, as those were the two languages he looked at before deciding to make his own Language. Anyways it took Ruby 10 years to gain enough mindshare to be succesful. D still might be successful, it's too early to judge.
Robert Gould
C# is not targeted at exactly the same crowd. It has a more idealistic view on language structure and a more pragmatic view on performance where D goes the other way.
Pyhton, Perl, Ruby, and JavaScript are all scripting languages. They don't compete directly against C#/Java and esp C++
@kts I have no idea what you mean, it seems like you misread the comments. No one suggested that scripting languages were in competition. Please re read the answer and comments.
Robert Gould
+12  A: 

I can think of a few reasons:

  1. User base is small. It's hard for new languages to achieve enough momentum to allow them to compete with the old players because there's less incentive for programmers to switch to them.
  2. Smaller body of knowledge (see previous). It's harder to find libraries, code examples, experienced developers, etc. This offsets any advantages the language itself has to offer in many cases.
  3. Maybe the language isn't the problem, and (yet) another language is not what we need. Most of what D aims to achieve by means of language features can be achieved in other languages in library-form.
Assaf Lavie
I think #3 is closest to the mark. D seems to have solved a problem no-one has.
+3  A: 

Another reason could be that, unlike C++, there is no international standard for the language. This effectively prevents third parties from implementing D language systems.

"International standard"? So people can't write a D compiler because the spec isn't maintained by a group? Nevermind the fact that the 1.0 spec has been frozen? (I believe third parties can't implement D compilers because the language has grown too complex, not because of other reasons).
+12  A: 

Because C++ programmers don't believe they need anything else. D offers a lot of cool things, but it doesn't change the fact that C and C++ are enough for developers. Also, I think the fact that it is considered a "Systems" programming language and that it's plastered on the D homepage makes people turn away before even looking at it.

What is C? C is _the_ systems programming language. Any dev who tells you that C and C++ are all they need is likely not a very good or extensible dev.
Adam Hawes C and C++ are considered General Purpose regardless of C being _the_ systems programming language. And what I meant is that most developers would say they don't need D because they have C/C++. You completely missed the point of my post.
That seems to be the general take. And they have a point as far as "the devil you know" bit goes. OTOH that doesn't imply that those people are correct all around.
This is just my opinion. It's not like anyone actually /knows/ the answer.
+28  A: 

No mature libraries and support documentation in general (most work is done by volunteers who do something for a bit then leave)

Also, I think the recent schism that Tango created doesn't help D at all.

hasen j
+16  A: 

For me, it's the lack of a high-quality IDE. If an IDE like Visual Studio or even Code::Blocks had full support for D, I would start using it in a heartbeat.

Matt Olenik
Yeah that is a valid point, the lack of a stadard IDE doesn't help. Wonder if there is an Eclipse plugin... there might be
Robert Gould
I really doubt that's a valid point. I mean, python still doesn't have a good IDE and it still took off. plus, real programmers can program with any old text editor.
hasen j
Python has tons of IDE support, almost every editor has a Python module. Lua on the otherhand doesn't have much mature editor support, emphasis on mature.
Robert Gould
there's an eclipse plugin called Descent
hasen j
Try the code::blocks nightlies.
@hasen j: Python has quite a few good IDEs, although not all of them are free. Also remember that Python is interpreted. With compiled languages like D, build integration can be an important factor.
Matt Olenik
On the Windows platform, Zeus can be easily configured to work as a D IDE -
+14  A: 

When you have established languages like C++ and Java ruling, why would one bother to switch to a new language? Moreover, C++ and Java have evolved over the years, with innumerable libraries to go with them. Not many would be ready to invest time to re-create those libraries for a new language as it would be a sort of duplication of effort.

learning new languages is always beneficial to your programming in the languages you already know
Accepted, learning a new language is beneficial. But, switching to that altogether is a different issue.
there nothing sort of switching.. Its passion and always looking for better.. I know why I love Python than my day work which I use C# and c++. I die for C++ in my time to learn so much. Now I better programs in C# and even better in Python.
Gopalakrishnan Subramani
Well I'm not talking about an individual here... as I told earlier, learning a new language is beneficial, but, as an example, what about the cost involved, if you were to port a whole project from one language to another? This is just one of the many negatives.
Again, it's just an opinion and I might be wrong.
Because Clojure is better. :)
Because if everyone always let inertia dominate their decisions, always tried to just improve the existing and lever made a clean break with old cruft, we'd be trapped in local optima forever.
+26  A: 

First of all: Most software developers I talk to have at least have heard of D and have it mentally connected to basically those properties that you mentioned in your question (Usually it's fast + the way C++ should have been implemented in the first place). This for itself is a level of success that 99 percent of all programming languages created will never reach.

There are some reasons though why it's not in the same league with Java/Python/C#/Ruby/etc.

  • The language itself is a nicely done - and sane - C++ successor. But it's not different enough from other static-type languages to really catch one's attention. It's enough for a friendly "ah, that's really nice", but not for "gee! I have to use this".
  • There is no killer application that requires you to learn D. Something that an average Joe programmer wants to work with so badly that he goes through the hassle of picking up a new language.
  • Dynamic programming languages such as JavaScript, Ruby and Python have taken over some big chunks of the language market, making it harder for compile-time-type-checking-languages to find an audience.
  • The corporate world is to a large extent JVM-world. Java might get replaced as an application development language anytime soon but its successor will most probably run on the JVM - because it's a pretty mature and stable piece of software with a large community and huge library resources. Most new JVM-languages such as Scala are compatible with already-written Java code.

And one last but very subjective point: I'm under the impression that the classical C/C++/Java-style-languages have fallen a little out of fashion in the part of the developer community that likes to check out new languages.

But all that said, D looks really nice and seems to solve the problems it promises to solve in a solid and fast manner. No reason why it shouldn't find its niche.

Greets Seb

D does have one WOW feature that makes me say "I gott'a have it": Template meta-programming for real humans.
I download Boost so I can do weird things while still being a mostly real human.
David Thornley
"The corporate world is to a large extend JVM-world." I though the corporate world was a .NET-world.
Isn't C++0x adding features to the C++98 to the extend that D is even less needed?!

Disclaimer: My experience with D is limited to seeing a few of the examples, reading the wikipedia page, and a hallway conversation.

As I said in an earlier comment, D seems to scratch an itch that no-one has. But beyond that, crap like this:

Note: all D users agree that by downloading and using D, or reading the D specs, they will explicitly identify any claims to intellectual property rights with a copyright or patent notice in any posted or emailed feedback sent to Digital Mars.

Guarantees that I won't read the spec, or do anything to promote its use. Nice to start with the legalese right away, eh?

if my english is not all lost, that just says you should state who has the right on the posted information. what's bad about that? i think it's good if state of the matter is clear. just append "copyright at clintp" at your email response and you're safe.
Johannes Schaub - litb
+1 litb. That clause doesn't seem unreasonable at all.
Michael Myers
The clause isn't the problem. The fact that right away, on their intro page, I'm having to parse legalese is the problem. If you want to get a language off the ground, it's a lousy way to go about things.
Somewhere in Joel on Software, Joel wrote about entry barriers. That's one right there. That legalese, right there, is probably enough to stunt its growth.
David Thornley
David: Exactly. It's just unnecessary BS at this stage. Bury the legalese in the LICENSE file or the .signature files, and if someone wants to use it in a production environment, let them figure it out then. Move the barrier back a ways.
After four years, I still don't know what that sentence means, but I really don't care about the fine print! and oh pleez do lie and say that you do care about the fine print.
hasen j
Look, this isn't legalese. It's straightforward English. "If you send us stuff that somebody else has a copyright on, point that out in the message. " That's _all_.
hansen/feeping: I don't care about what the fine print says, I care that it's there. It's bad UI. Initmidation. Unfriendly. Marketing fail. It's silly to wonder about lack of interest in the face of stupid crap like this. The OP asked about lack of interest: I'm answering this as *one* cause.
Fair enough. I'm sceptical that that's a common problem though.
This is a very fair agreement and it all it says is to respect patents and copyrights of the owner if digital mars gets attacked with lawsuits and/or warn digital mars first before suing. There just playing it safe.
Tim Matthews
I'm reading it differently: if you find that D steps on any IP rights, please tell Digital Mars. Well, "please"... You *must* tell Digital Mars.
@Bart, you're reading it wrong (I read it the same way at first) - FeepingCreature has it correct, and it's a very reasonable request in my view. It's also one that *really* *does* need to be pointed out very clearly up front in order to protect DigitalMars. Don't hate DM for it, hate our litigious environment.
Software Monkey
+6  A: 

I think there are a few problems:

  • Tango/Phobos split - the compiler writers use Phobos, but nearly everyone else likes Tango better and ends up using that.
  • Lack of a great compiler - DMD is quite buggy, and all the other compilers use the same frontend. It is quite easy to crash. I'd really like to see dil (D compiler written in D) working, but they have a lot of work to do before it will become a good competitor.
  • Competition - Java and C# are quite similar, and have much more support, so everyone uses those.
The DMD back-end has been opened recently, so that should be looking up.
Really! That's nice, but I like GDC and LDC better.
Java and C# *are* similar. And for application-level programs (for some handwavy definition of "application"), the JVM and .NET ecosystems are great, and people should write in those languages. But if you are doing systems code, moving beyond the limitations of C and C++ is well worth considering.
@quark: D is really meant to be used with GC, which will not work well with systems code. But D is a really nice language for application dev (it's certainly a much nicer language than Java, but C# is close).

For me, the language is not reflective enough. It doesn't has reflection, so programmer doesn't show interest. It is not supporting reflection, may be due to its machine dependencies.

If you see the latest framework developed using C# or Java, they tend to support dynamics through Inversion of Control. IOC allows to configure the system in the XML/other format and create the objects at the runtime. Much of innovation is possible if it support the reflection. DLLs & executable should provide meta information about itself.

The classes, functions, attributes must be hooked. Otherwise I loose the interest hacking the language.

I don't know who marketed Perl or Python or Ruby. If the language attracts hackers, they tend to create framework or application at home, eventually it will attract the other programmers.


I don't see in the example the site is illustring, any real noticable difference between it and C#. I think that C# is more clear and clean.

I don't see why I should use it instead and I don't figure out what benefit it offers...

Omar Abid
D is not really a replacement for C#. C# has the advantages of CIL and .Net reusable frameworks and classes all of which can also be a huge disadvantage like .net not installed or statically compiled features like inline assm for example.
Tim Matthews
The current controversy of C#/Mono on Linux is a clear indicator of why one would prefer D over C#, and that is not even considering language features.
Try evaluating a regular expression with C# at compile time
Johannes Schaub - litb
+21  A: 

To me, a major holdup to wider adoption is that the language is still so rapidly evolving. D1 is/was a relatively conservative attempt to create a better C++ by adding some lessons learned in the past 20+ years from languages like Java and Python. It's a nice language, but it doesn't have any huge killer features, so it's understandable that switching costs would be enough to discourage people.

D2, on the other hand, is still in alpha, but represents much more significant innovation. It attempts to bridge the gap between functional and imperative programming, with features such as:

  1. Transitive const (Anything reachable from a const/immutable object is itself const/immutable).
  2. Pure functions. You mark a function as pure and the compiler enforces that it can have no externally visible side effects. It may, however, use mutable state freely as long as it's not visible outside of the pure function.
  3. Shared. This isn't implemented yet, but the idea is to make all data unshared between threads by default, have the compiler automatically insert memory fences, etc. when needed if data is shared, and have the type system prevent accidental sharing.

D2 also adds some features to make D more friendly to library writers, such as return by reference, alias this (basically an implicit cast operator), template alias arguments (basically passing any compile-time symbol as an argument to a template), template constraints (similar to C++0x concepts), and real closures.

The take-home message here is, give D time. D1 is a nice, but relatively conservative language. Most of the really impressive killer features are in D2, but it's still in alpha.

+10  A: 

I like D in that it's a lower-level (C/C++ level) language that has many of the conventions and features I like in C#. It's a good mix. It does have a lot of downsides right now though:

1) Standard Library Split - Phobos vs Tangos splits all the code done in D. This could fix in D 2.0 with the Phobos improvements, but I see this continuing until Digital Mars adopts the community run Tango as the official standard.

2) Version Split - D 1.0 is a fairly stable and solid platform for writing code on, but D 2.0 promises many new features, some of them breaking. It is also explicitly an unstable platform to build on. Until D 2.0 is stabilized and released, the language is going no where.

3) No good IDE - There's just nothing great out there. Eclipse plugins and a few half-baked editors exist, but no true coding environment. I think this is just a matter of time, as a number of good starts are out there, being worked on.

4) Lack of libraries/killer-apps - This is something of a chicken/egg situation. There are some great libraries for D, particularly since you can wrap any library written in C very easily. There are actually a lot of good libraries for D out there, and some nice apps too. I think when the above issues are solved, more programmers will come to D and then it'll have the cool apps it needs to attract a wider base.

The latest version of SlickEdit has D support, and SE is my favourite C++ IDE. I haven't tried it though.
+54  A: 

There are two standard libraries and 3 or 4 variously broken compilers, but others have already mentioned that.

Once you have chosen a library (phobos for me), and got a mostly working compiler, you discover that D (the language) has many little problems. On their own they are small, but together they make D programming somewhat painful.

  • Unicode is dealt with in a somewhat strange way - there are three different unicode string types: char[], wchar[] and dchar[] - the standard is char[], in which unicode is stored encoded as utf-8 - and conversions between utf-8 and codepoints (dchar) are required in various places (and sometimes are implicit). char[i] will however yield the ith byte, not the ith codepoint... Strings are also mutable, you must implement copy-on-write yourself.

  • Arrays are strange. Some are static, some are dynamic. int[] x = null; makes x an empty array. Literal associative arrays (which are a great feature) with strings as keys must have all the keys the same length or use a syntactic hack to work around a type deduction problem - it works but its kindof ugly.

  • Arrays are not regular objects, and do not have instance methods as such (no indexOf for example) - but there are weird rules regarding functions that are in scope and take an array as their first argument to create the illusion of instance methods...

  • You can sometimes call methods without the braces.

  • Functions that form closures or are attached to objects (i.e. methods) are not the same as regular functions, instead they are called delegates, and you must be aware of the differences.

  • Literal strings (char[]) can be defined with x"40fe", to specify the bytes in hexadecimal that make up the utf-8 array. The D website says that specifying an illegal utf-8 sequence is allowed, but my compiler disagrees.

  • Standard library modules (phobos) often take semantically incorrect arguments as function arguments (e.g. taking char[] where it should take ubyte[]), or force you to use strange conventions (ubyte b;; instead of ubyte b = inputStream.readUByte();.

  • There is a for-each loop, but the syntax feels icky compared to Python or even Java: foreach(ubyte b, char c; "abcdef"){ ... }. for(ubyte b, char c in "abdef"){ ... } would be nicer (though not much...). It has optional type inference for b and c though.

  • You cant make a read only class by const class X {}, because "methods cant be const".

  • The cast syntax: ubyte u = cast(ubyte) 300; is too verbose.

  • You can cast invalid values into an enum type: enum X : ubyte {a=0, b=1}; X z = cast(X) 10; gives no error - z is now 10.

  • The feeling I get is that if I keep evaluating D I will find more little problems that don't really matter so long as you do X and Y, but I just don't want to do X and Y...

  • It is really hard to google for things relating to a language called "D":

The cast syntax is verbose by design. Forbidding casting invalid values to an enum would require a potentially rather costly run time check that isn't in line with D's system level roots. It would also forbid using them for bit flags.
could you elaborate on what you don't like about foreach? Personally I like it better then the other foreach I have to use: C#.
Google: What generally works for me is "d programming". It usually finds what I need though I agree it isn't perfect.
I have to admit here that the weird design of `read()` on Phobos streams was my bad design decision back in the day when I was active in D community (which was several years ago, waaaay before 1.0 release) - I wrote the first version of streams for D. Not sure what was the rationale for this, but my guess would be uniformity of calls. Anyway, I'm surprised they've kept this bit as is since then.
Pavel Minaev
FYI, the enum problem you mentioned is the same in C#
Richard Szalay
It seems to me you could make a list like this about any programming language. And some of these are very small nits being picked, personal preference, or misunderstanding.
+3  A: 

I have looked into D and I liked what I have seen, especially the release 2. Unfortunately, until now there only seems to be reasonable Linux and Windows support, but not for Mac OS X. On Mac OS X, it is far from being production-ready which is the killer for me. Too bad, because it really looks like a reasonable alternative for native application development and even integration of C libraries was surprisingly simple for what I used it so far.


I am always looking for something just like D. A C that has some of the rough edges taken off and modernized. Many times I have installed and attempted to get D to work. D doesn't work well straight out of the box and it's a moving target. However, the real problem is it isn't compatible with legacy C code. Oh, you say it does? No it doesn't. You still say it does? No it doesn't. The issue is that although it will bind with C .o files, the .H files are NOT compatible. This means I have to re-write all the headers for anything I want to link to, and then when updating the .h file forever in the future, convert it to D format again. This process can not be automated, and it sucks. That's the main thing that turns me off. Might as well call it Q or Frak or Whatever since it's not as related to C as it is advertised.

+1  A: 

I think it's a matter of timing. This is the day of interpreted and byte-code languages for those picking up new languages. Python, JavaScript, Ruby, C#, Java, Scala, Groovy, PHP, ActionScript--a lot to learn without diving into a new competitor to C++.

Anyone using C or C++ is probably pretty happy with C or C++. What's the compelling argument to take them away from their familiar and productive environments and make them learn a language that sounds like a bump to C?

There are many reasons to use C or C++ that don't necessarily preclude being unhappy with the language.
+5  A: 

For me, the most exciting feature of D is the ability to code in UTF-8. How wonderful is that!

There may be other languages that allow international characters (not C++!), but I've been in the C and C++ world and D is the only one that I know of that supports UTF-8.

It is very tiring to find symbol names that are unambiguous when the accents are stripped off: döndür() and dondur() have completely different meanings in Turkish: 'return' vs. 'freeze'.

Consider sıkıcı() vs. sikici(); meaning 'boring' vs. [a swear word].

I think D can be very popular if the international character support is pushed forward, which I will be doing on my Turkish D site.


Ali Cehreli
+4  A: 

I use D. What I like is fast compilation speed. I had an idea, and I could implement really fast. Imagine when compilation speed is about 1 second. ( A similar program compiles in 8 seconds in C++.) If one knows what to do, one can fly. Flexibility of the language is many times wish-fulfilling. It happened to me I thought of a feature, I tried it and it was implemented. Helpful language constructs: foreach, templates, lists can be specified/initialised than in C++, structs can be initialised in their definition, automatic type inference, easy to initialise structs, compile time function evalution, associative arrays and dynamic arrays are built-in as well as garbage collection which can be turned off.

I could add there are problems (as already mentioned by others): buggy linker, missing high-quality IDE, not the best debugger (ddbg) (C++ debuggers are better), less libraries than for C++, operator overloading is more restrictive (less operators can be overloaded), multiple inheritance is not supported (there are mixins). Note that C libraries can be used, C++ can be used too with limitations (I have not tried that).

I use D for console programs.

Update: linker seems to be ok now for D1.

It's probably worth mentioning that for a systems language, it is remarkably difficult to find a compiler that will let you write system code against the bare metal of a computer without giving strange and often cryptic error messages.

Personally, I'm crossing my fingers for the LLVM front-end to mature into a more useful creature than the stagnant GNU gdc, and the unwieldy Digital Mars dmd compilers.

Reading around D2, it should be a really nice language if well implemented and if it has a vaguely reasonable level of tools support.

+4  A: 

My guess is that D is positioned as a "better C++", but C++ is good enough and has huge inertia, so D is not going to be big.

For higher level coding you already have a lot better languages than either C++ or D.

+1  A: 

I'm in the process of looking into it at the moment, and by far the greatest impediment to my evaluation is the lack of a clear guide to the language.

In the past, languages had books that came along with them (in the time when you needed about 80 floppy disks to install a language), then along came interpretted languages, java and C#. These all had good web based guides, clear easily accessible documentation, or an IDE with some form of intellisense. All of these resources (or even just 1 of them) could point you in the direction you needed for any simple questions you have (and it's always the simplest things that trip you up).

There's no easily referenced guide to the D language. As mentioned in one of the other posts, you can't google it easily (though 'D programming' or 'd language' sometimes work).

An example I had was how to strip punctuation from a string, what methods are exposed for the 'string' object (no resource like javadocs for D, so need to google it). It turned out I needed to import and use std.regex and was fairly simple, but I still don't have any docs telling me exactly what 'string' exposes (or any other object for that matter).

On a related note, not specifically about D though (BTW, this could only be me). In the beginning, I relied on actually knowing the syntax and libraries I used inside out, now, I've found that I generally just know the summaries of the libraries I use and use the intellisense or javadocs (or whatever for other languages) for details. Any language without an easily referenced documentation system will be at a disadvantage.