What development environment do you prefer for D? Old fashioned Vim/Emacs and the like, or any of the IDEs I see listed in the wiki (http://wiki.dlang.org/IDEs)?
I've discovered D six years ago after reading Andrei Alexandreuscu's article "The Case for D" in one of ACCU's publications. D was a gasp of fresh air especially for people coming from C++ like myself.
I used to frequent C and C++ forums on Turkish web sites and was aware of the need for up-to-date software documentation. I saw D as an opportunity to ensure that for once, Turkish documentation would not be behind the English ones. I started writing HTML pages without any idea that they would become a book later on.
Then I've decided to use the tool Prince XML (free for personal use) to see the pages in book form. I made that PDF version available as well.
I had never thought that my work would be valuable for an English-speaking audience. Then, Andrei and others convinced me that it would be a good idea to translate the book to English as well. I did that, added many more chapters, edited heavily (mostly by Luís Marques), and it worked!
As far as I know, the book is the first software documentation that was translated from Turkish to English, as opposed to the other direction.
D is a general purpose language. I don't know the status on the IOS/Android front. gdc, the D compiler using GCC back-end; and ldc, the D compiler using LLVM back-end can produce code for the platforms that those compilers support. However, don't take my word on that. I would expect issues.
D is a compiled language that is as low as C (and of course inline assembly) and as high as Python and others. One benefit over Go is the fact that D's template support is the best that I know of. When compared to D's C++'s templates are almost unusable; very clumsy.
Go: Generic type-safe highly efficient code. Can go lower-level like inline assembly. Can go higher-level because more meta programming.
Python: Faster. Static typing.
Ruby: See Python.
Java: Less boilerplate. More control over memory management. More meta programming. Natively compiled.
Rust: Easier. Garbage collection makes programming just as safe and is easier to use. Looks and feels more like C/C++/Java, if you already know them. More meta programming.
I think you misunderstood me, because I used "lazy". It has nothing to do with Haskell lazyness.
In Java static fields are initialized when a class is loaded by the class loader. A class is only loaded when used. If anything (IO,scheduler,etc) changes the order in which classes are used, then initializers are called in a different order and their side effects as well. This semantic is mandatory by language definition.
In a Java AOT compiler this means every access to a static field must be prefixed with a (synchronized) check if the class is already initialized and optimizing it away is rarely possible. A JIT compiler does not even care, because it knows the class is already loaded.
For contrast, in C++ static fields are all initialized before main is called.
Actually I don't know how the current AOT compilers approach that situation.
Now with Oracle taking the steps to eventually make AOT compilation also a feature in the reference JDK, I suppose whatever issues might still exist they will be tackled.
All of them: Language is more complex and takes longer to learn. Less community. Less libraries.
Python: D cannot be as close to pseudo code, mostly due to static types.
Rust: Borrow checking looks like a nice idea. The question is, if the cost is worth it.
As a language, I think D is clearly better than Java and Go. Go has better tooling. For example, go-fmt is production quality, while dfmt is alpha quality.
Ali