The D Programming Language, Version 1.0

penguinblotter writes in a journal article: "Soon, Walter Bright is scheduled to release version 1.0 of the D Programming Language. D is a systems programming language. Its focus is on combining the power and high performance of C and C++ with the programmer productivity of modern languages like Ruby and Python. Special attention is given to the needs of quality assurance, documentation, management, portability and reliability. D has appeared on Slashdot a few times before, and Walter has continued to add more and more features. Most Slashdot community comments in these articles have been offered on feature X or spec Y without reading through the extensive D newsgroup archives. It has been here over the past seven years where extremely gifted and experienced programmers hashed out discussions and arrived at excellent implementations of all the ideas discussed." Read on for the rest of penguinblotter's writeup.
For those with a C/C++ background, D offers:

• native code speed
• extremely fast compilation times
• garbage collection (although you can manage your own memory if you want)
• OOP - by reference only, easy initialization, always virtual
• cleaner template metaprogramming syntax, more powerful templates, as well
• built-in dynamic and associative arrays, array slicing
• versioning (no preprocessor madness)
• link-compatibility with C
• nested functions
• class delegates / function pointers
• module system

For those with a C#/Java background (a shorter list, but one with big wins):

• similar syntax
• No virtual machine or interpreter
• built-in unit testing and design-by-contract

These two comparison sheets can go into more depth on how D stacks up against other languages.

From D's creator:
For me, it's hard to pinpoint any particular feature or two. It's the combination of features that makes the cake, not the sugar, flour or baking powder. So,

1. My programs come together faster and have fewer bugs.
2. Once written, the programs are easier to modify.
3. I can do (1) and (2) without giving up performance.

Get your compilers and start hacking D!

• DMD (Digital Mars reference compiler, Windows & Linux, x86)
• GDC (GCC front-end)

Comments

Re:D is surprisingly good.

[matrixise]

from http://digitalmars.com/d/interfaceToC.html

D does not provide an interface to C++. Since D, however, interfaces directly to C, it can interface directly to C++ code if it is declared as having C linkage.

D class objects are incompatible with C++ class objects.

Currently learning D

[kihjin]

Note: I've been programming in C/C++ for four years.

I took it upon myself to learn D not more than a few weeks ago. A classmate introduced me to the language last spring.

While I'm still learning D, it has some notable features:

• auto keyword for inferred type declaration
• lazy keyword for evaluation
• delegates are like function pointers, but cooler. Literal statements can be passed as variables, and aren't evaluated until the delegate is called.
• scope(exit|failure|success), specify a block of exit code
• in/out/inout function keywords, offer readable code for determining what a parameter in a function is designed for.
• get/set methods automatically become a property (accessed like a public variable)
• foreach, foreach_reverse, container iteration
• with statement, C++'s using on a object-level

Of course one may argue that none of this is necessary and could be made independent of the language itself. My belief is that would increase the complexity of coding in D.

If you're interested in D you should visit http://www.dsource.org/. There are some interesting projects such as Derelict (collection of C game bindings) and Bud (make and SCons replacement).

Re:java native code compilation

[Decaff]

Java isn't that much slower if you actually take the time to compile it to native code first. Using something like a JIT compiler http://en.wikipedia.org/wiki/Just-in-time_compilat ion can greatly increase the speed of your code and put it close in line with C++.

This is a bit of an old myth. Almost all Java is run as native code these days, even on VMs, and is mostly pretty close to C++ speed. Benchmarks that show Java as significantly slower than C++ usually result from not allowing the VM enough time to perform native code translation of time-critical code. Java has moved away from JIT compilation (as against the later optimisation of HotSpot) because it led to long start-up times - you had to wait for code to be compiled to native before it ran. Now Java usually starts up as interpreted, with the translation to native code happening later on, in the background.

Where C, C++ and D win out over Java in terms of performance is when you need programs that have to start up fast, run fast, but only for short periods (a few seconds).

Re:GC, No Vm or performance hit

[Anonymous Brave Guy]

garbage collection ... No virtual machine ... How do they square that particular circle?

The same way as countless other programming languages have in the past, I imagine. Why do you think garbage collection requires running your code under a VM?

Just In Time Compilation in C# or Java has "Native code speed", in fact it goes one better - since the compilation happens at a later time, more processor or other specific optimisations can be made.

Of course, you're overlooking all the overhead of monitoring the code long enough to determine which on-the-fly optimisations are worth performing, and of compiling the code itself, neither of which is trivial.

GC has a lot to do with the perceived slowness.

True, though of course it's not without overheads. Almost all of the Big Claims(TM) made by GC advocates in these discussions come with a catch: state-of-the-art GC method number 17 has a lower amortised cost of memory recovery than explicitly freeing it C-style!*

* But only if your system contains 10x as much memory as the program will ever need anyway.

This is traditionally followed by a wisecrack about how memory is cheap, followed by three enlightened posters pointing out the stupidity of that argument for multiple reasons. :-)

Isn't it disingenuous to tout both "native code speed" and "garbage collection"?

That depends a lot on context. If you really have a system where the overheads of GC are trivial but all the advantages are present, it seems a fair claim. It's just not likely to be universally true, and representing it as such would indeed be disingenuous.

Re:This won't work...

[TERdON]

Now, after F do we get G or 10?

Either it'll be called 10, or H. G, has already been taken, not only once, but twice.

For your reference (kudos goes to Wikipedia), the following single letter (sometimes including some additional nonalphabetic characters) have also been implemented:

A+ A++ B C C-- C++ C# D E F F# G (now known as Deesel) G J J# J++ K L M4 Q R S S2 T X10

So - that only leaves you the letters H, I, N, O, P (sic!), U, V, W, Y and Z if you don't want to have a name clash with another programming language. Technically, M and X are followed by numbers in the previous examples, so you could argue for them as well, and even A (as it has a plus behind the letter)

I'm mostly surprised that noone has thought of a (P)rogramming language. :)