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

D is surprisingly good.

[FishWithAHammer]

I'm looking at using it via GDC for my next project. For people who use C/C++ regularly, this is something you ought to look into.

It's not a toy language. If you're a C++ programmer, you'll be almost immediately functional in the language. And you can call C and C++ libraries seamlessly. It's pretty sweet.

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.

Re:D is surprisingly good.

[eluusive]

Please see: http://dsource.org/projects/bcd

Re:Weird writeup:

[91degrees]

Couple of points:

* native code speed

I think this is a response to criticisms from C programmers about most modern languages, rather than a benefit over C.

Not exactly a recommendation that the core language apparently is so weak that these can't be put into libraries.

Some of this is useful enough to be built in. stl and the like are pretty handy but sometimes it feels a bit of a kludge. Plus, built-in allows better optimistations for specific cases.

Obviously both C and C++ have function pointers.

Yes, and the syntax is horrible. D makes this a lot nicer.

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

[Nasarius]

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

It's really not that difficult. Hans Boehm wrote a garbage collector for C/C++ years ago, which happens to be the same one that the Digital Mars implementation of D uses.

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

Re:Because the ones we have suck?

[TheRaven64]

There is no such thing as an interpreted language. There are languages, and there are interpreters and compilers. Lisp, for example, can be both interpreted and compiled (Scheme is usually interpreted and Common Lisp is usually compiled, but there are exceptions). Tcc can both compile and interpret C code. Java can be compiled by something like gcj or interpreted by a JVM. If you compile Java you lose some of the features; the JVM bytecode format is designed so that it is easy for automated tools to reason about. At load-time, the JVM will parse the class files and check that they do not violate the Java security model; this is theoretically possible with compiled code, but much harder.

The Squeak runtime for Smalltalk is written in Smalltalk. There is a smallish subset of Smalltalk used to write the basic functionality, which is compiled to native code. This then supports the whole language. The same model is, I believe, used for JNode, an operating system written in Java...

Re:This won't work...

[LunarCrisis]

Though I agree with you for the most part (finding the nth character in a UTF-8 string is unnecessarily long), this is wrong:

searching for a character just requires you to compare each 32-bit value to the target, without having to check it isn't a special character that is the first in an escape sequence UTF-8 was designed so that no complete set of bytes representing a character occurs as a substring of any other. This makes the search problem into a simple search for a string inside another string. The searching routine doesn't even need to know whether or not it's a UTF-8 string or not, just as long as it doesn't mangle the last bit.

Re:This won't work... D Strings

[Anonymous Coward]

While D strings are mostly implemented as character arrays, it works quite differently than C. Here are some notable differences:

- D arrays are bounds checked. No accidental buffer overflows here.
- D arrays are dynamic, you can resize them and concatenate them together.
- D strings are D arrays, so they get the above bonuses.
- D has distinct 'char', 'byte', and 'ubyte' types. char[] != ubyte[]. When you use foreach to iterate over a char[]/string, it will expand each codepoint (or whatever they are called) to a dchar (which is a 32 bit character) for you. ubyte and byte are used for plain-old-data, instead of the unfortunate C char.
- Garbage collection frees you from worrying about where the strings go. No accidental memory leaks here.

There is also a nice alternative to the plain old strings called dstring, which gives you even more benefits of d's arrays like indexing and slicing (you can safely leave foreach alone with it). http://www.dprogramming.com/dstring.php

I've used both D strings and C strings, and D's strings just felt so much better.