In my experience, so does Nim. Yes, it's at two-step process, but the translation to c-code is blazingly fast, and the generated c is of the clean and straightforward kind which gcc or clang can handle in a highly efficient way.

For the same design; what sets fast code apart from slow code is the availability of designs enabled by the language. Compile time computation is a huge win for D (IIRC nim has similar capabilities).

As to C/D/C++/Rust/Nim, what I think is interesting to see, is which ones lead you to the performant path naturally, vs having to really dig into the bowels of the language or go against the grain of the language, so to speak. I have not written enough of any of them to say which do this. I would hazard that Rust does the best job, due to its explicitness / very nature.

D's big advantage is the plasticity of the code, meaning it's much easier to try out different data structures and algorithms to compare speed. My experience with C and C++ is they're hard to change data structures, meaning one tends to stick with the initial design.

For a smallish example, in C one uses s.f when s is a value of a struct, and s->f when s is a pointer to a struct. If you're switching from one to the other, you have to go through all your code swapping . and ->. With D, both are .

I might say the same about c, except even more so.

As for 'the performant path', something to watch for there is jai, probably coming out later this year. It has clever things there, like dynamically switching between SOA and AOS, or doing small dynamic allocations on the stack.

[0] https://dlang.org/blog/2017/08/23/d-as-a-better-c/

IIRC, Walter has said somewhere (likely on the D site or on his site or one of his articles for DDJ) that it was designed for that, actually, or something to that effect [1]. I've felt that myself while using it. I think he also said something like the code should look good on the page.

I agree.

[1] Or at least, make him happy :)

https://jugad2.blogspot.com/search/label/DLang

They may be of interest to beginners or others wanting to get a bit of a feel for some of the kinds of things D can do, via simple command-line programs, along with checking the D site and tour at dlang.org .

If it's the same studies I'm thinking of, the result was that productivity was about the same in all languages _when measured in lines of code per day_.

So say 1k lines of assembler took the same time as 1k lines of Python. However, the higher level languages can _do_ more for the same number of lines.

There are things I can do with a few lines of code in Python that when I looked at how to do in lower level languages I just decided I could live with slower performance.

But I've seen literally 1000x speedups from transferring the numerical heavy lifting to C++, which paid back the time it took to rewrite that code in very short order and enabled us to do something that wasn't previously close to practical. I was pretty sure that the benefit would be closer 10x, but nope!

So what I mean is that the python program leveraged numpy to the greatest possible extent (that I know how), but was nonetheless 1000x slower than the C++ program that produced the same output. I am not making any claim that particular operations like summing up an array or doing an FFT is 1000x faster in C++ than in numpy. Of course it's not. In this case, numpy calls were certainly not the bottleneck, so it would be wrong to say "1000x faster than numpy". But it was, on the whole, 1000x faster than Python leveraging numpy.

No, Nim is often among the fastests, sometimes surpassing C. This is because it targets C by default and uses data structures and code paths that GCC can optimize very well.

That's not necessarily true.

For example language semantics (essentially how much information the optimiser has) such as whether mutable pointers are allowed to alias (or even the existence of non-mutable pointers) can play a huge role in what optimisations can be applied in a given situation and even how effective certain optimisations are. Also default behaviours like D, rust, and nim doing bounds-check can change the practical speed (although not necessarily theoretical speed) of a language. And finally things like garbage collectors can make certain languages faster in some cases but slower in others (again there's a practical vs theoretical argument here, since you could get similar speed-ups using other techniques).

So no they don't necessarily have to have comparable performance, at least not in all situations.

D's contract mechanism (i.e. in/out, and invariant blocks) can provide very strong guarantees to the compiler (as a specified part of the language as opposed to a GCC pragma/builtin), which the LLVM D compiler definitely uses.

All of the on by defaults that D has are usually there for a reason, i.e. floats are NaN initialized and bounds checking is on by default: These are very good idiot-proofing which can often be ignored unless profiling suggests there is a tangible issue.

That's awesome. I didn't know LDC uses contracts like that. It'd be nice to have similar functionality across all D compilers.