Inherent code performance advantages of D over C?

[qznc]

On Saturday, 7 December 2013 at 00:26:34 UTC, H. S. Teoh wrote:
> On Sat, Dec 07, 2013 at 01:09:00AM +0100, John Colvin wrote:
>> On Friday, 6 December 2013 at 23:56:39 UTC, H. S. Teoh wrote:
>> >
>> >It would be nice to decouple Phobos modules more. A *lot* 
>> >more.
>> 
>> Why? I've seen this point made several times and I can't 
>> understand
>> why this is an important concern.
>> 
>> I see the interplay between phobos modules as good, it saves
>> reinventing the wheel all over the place, making for a smaller,
>> cleaner standard library.
>> 
>> Am I missing something fundamental here?
>
> It's not that it's bad to reuse code. The problem is the 
> dependency is
> too coarse-grained, so that if you want to, say, print "hello 
> world", it
> pulls in all sorts of stuff, like algorithms for sorting arrays 
> (just an
> example, not the actual case), or floating-point format parsers 
> (may
> actually be the case), which aren't *needed* to perform that 
> particular
> task. If printing "hello world" requires pulling in file 
> locking code,
> then by all means, pull that in. But it shouldn't pull in, say,
> std.complex just because some obscure corner of writeln's 
> implementation
> makes a reference to std.complex.

What is the actual problem? Compile times? Binary size? Surely 
not performance or efficency.

I remember someone from the Go team (maybe Pike), that they have 
deliberate code duplication in the standard library to decouple 
it. I did not understand the reasoning there, too.