Why isn't the 'D' language picking up?

Question

Anybody using language 'D'?

Why isn't it more popular?

Answer 1

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.

Answer 2

http://en.wikipedia.org/wiki/Switching_barriers

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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

Answer 10

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?

Answer 11

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.

Answer 12

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.

Answer 13

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...

Answer 14

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.

Answer 15

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.

Answer 16

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; inputStream.read(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": http://www.google.com/search?q=d+modules

Answer 17

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.

Answer 18

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.

Answer 19

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?

Answer 20

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

Answer 21

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.

Answer 22

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.

Answer 23

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.

Answer 24

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.