Inherent code performance advantages of D over C?

[bearophile]

Dicebot:

>> 2. dependable sizes of basic types
>
> Not a real issue as your platform SDK always includes some kind 
> of "stdint.h"

On the other hand in D you have less noise. Most D modules you 
find around use and will use the built-in types, instead of 
choosing every time different ones. This uniformity is an 
improvement.


> Would have called this a feature if one could actually use 
> something instead out of the box. But there is no way to 
> control symbol visibility right now so templates / CTFE are 
> often out of the toolset. And what to do without those?

This should be fixed.


>> 9. modules
>
> Other than (1) it is also more a problem than help in current 
> implementation

Despite their flaws, D modules are quite handy, and better than C 
way of managing source code files.


> you need to care also about emitted ModuleInfo.

I think LDC2 has a pragma to disable module info generation. 
Can't something like that be standardized for all D compilers, 
including D? Have you opened well reasoned enhancement requests 
for your desires?


> Not an issue. C programmers are not tired from typing.

That's a silly answer. When it works (and it's working more and 
more), the freedom it gives is handy.


> Nice but just a syntax sugar yet again.

Having less cluttered code is an improvement.


>> 16. struct alignment as a language feature rather than an ugly 
>> extension kludge
>
> Same as (11)

Having built-in standard features save you troubles and work.


>> 19. no need for global variables when qsorting
>
> Doesn't matter

Why?


>> 20. no global locale madness
>
> (no idea what this means)

I think Walter refers to this kind of stuff:
http://www.cplusplus.com/reference/clocale/


> `auto` has no real value in C world because there are not crazy 
> template types.

"auto" can be handy in C-like code too (but it's less needed 
because the types are simpler), to avoid repeating struct names, 
to avoid repeating types two times when you call malloc, etc.


> @safe is a joke for barebone, you almost never be able to apply 
> it :)

I think you can have some safe functions in C-style code too :-)


> - Allocation for stuff like array literals making those 
> unusable once you remove runtime away

There is hope to remove this problem:
https://github.com/D-Programming-Language/dmd/pull/2952
https://github.com/D-Programming-Language/dmd/pull/2958


> - No internal linkage or reliable LTO  - no way to take care of 
> unused symbols and control binary size / layout

This could be worked on.

And now instead of negatives, let's talk about missing positive 
features. A future replacement for the C language should allow 
the kind of low level code you use in C, and also offer ways to 
express more semantics to the compiler, that will be verified and 
enforced, to make the code safer. Currently the only language I 
know that is a bit like this is the ATS2 language 
(http://www.ats-lang.org/ ), and it's partially a failure. (D and 
Rust are more replacements for C++ than for C). There's still 
plenty of work to do in the design of low-level languages. A 
compiler for such (probably imperative) language will probably 
need to contain a SAT solver, and more inference skills.

Bye,
bearophile