10 comments

[ 2.4 ms ] story [ 31.7 ms ] thread
The "static if (directed) { <code> }" part threw me for a loop. The comment says it's evaluated at compile time to control whether the methods are included. That's pretty neat!
You can also call pure D functions at compile-time, along with mixins this gives you something close to the power of Lisp macros.
It could be cool if Google had just pushed D instead of creating Go...
As bsaul hints at, isn't Google, it is the people behind Go. Google didn't say, let us make a new language. Instead employees ask management if they could work on a language. Given this perspective it is easy to see why supporting D wasn't chosen.

Even so, D is making good progress and has a good community to keep it alive for a long time to come.

interesting network representation! after being confused for a little, it just looks like a pair of compressed-row sparse matrices - one matrix for the forward edges, and the other for the reverse edges. which then seems like a pretty sensible thing to do, if you care about directionality.

(e.g. http://web.eecs.utk.edu/~dongarra/etemplates/node373.html) (edit: without the coefficients, of course, unless you want edge weights)

Yes, D is not a small and simple language. The goal as stated at DConf was to be "comprehensive". D shall include the right tool for any job in system programming. That necessary includes that the programmer has lots of options.

You can use threads or fibers. You can meta-program with various degrees of freedom (and danger) up to generating arbitrary code strings during compilation. You can use high-level parallelism tools like parallel map and thread pools. You can explicitly use SIMD operation for instruction level parallelism. You can have a garbage collector or you can disable it.

On the other hand, D fixes a few problems of C++ (which mostly come from C source code compatability) like ambiguous syntax for templates (Is ">>" a shift-right token or two closing "parens"?).

In the back of Stroustrup 4th ed, there's a list of at least a couple dozen things Stroustrup considers problems arising from C back compatibility, but I don't have the book with me
C++'s template syntax is not a result of C source code compatibility.
So why did they not pick something better like foo!(a,b) instead of foo<a,b>? Because parsing was not as well understood as it is today?