Microsoft working on new systems language

[Jonathan M Davis]

On Sunday, December 29, 2013 07:22:28 Andrei Alexandrescu wrote:
> Clearly there's work we need to do on improving particularly the
> standard library. But claiming that D code can't be efficient because of
> some stdlib artifacts is like claiming C++ code can't do efficient I/O
> because it must use iostreams (which are indeed objectively and
> undeniably horrifically slow). Neither argument has merit.

D's design pretty much guarantees that it's as fast as C++ as long as the 
application implementations and compiler implementations are comparable. It's 
too similar to C++ for it to be otherwise. And D adds several features that 
can make it faster than C++ fairly easily (e.g. slices or CTFE).The only D 
feature that I think is of any real concern for speed is the GC, and C++ 
doesn't even have that, so writing D code the same way that you would C++ code 
would avoid that problem entirely, and you can take advantage of the GC 
without seriously harming performance simply by being smart about how you go 
about using it. The main issue is what your implementation is doing, as it's 
easy enough to make a program slower in either language.

I think that the real question at this point is how fast idiomatic D is vs 
idiomatic C++, as D's design pretty much guarantees that it's competitive 
performance-wise as far as the language itself goes. And if idiomatic D is 
slower than idiomatic C++, it's likely something that can and will be fixed by 
improving the standard library. The only risk there IMHO is if we happened to 
have picked a particular idiom that is just inherently slow (e.g. if ranges 
were slow by their very nature), and I don't think that we've done that. And D 
(particularly idiomatic D) is so much easier to use that the increase in 
programmer productivity likely outweighs whatever minor performance hit the 
current implementation might incur.

I agree that anyone who thinks that D is not competitive with C++ in terms of 
performance doesn't know what they're talking about. How you go about getting 
full performance out of each of them is not necessarily quite the same, but 
they're so similar (with D adding a number of improvements) that I don't see 
how D could be fundamentally slower than C++, and if it is, we screwed up big 
time.

- Jonathan M Davis