libc dependency

[Cym13 via Digitalmars-d-learn]

On Monday, 19 June 2017 at 21:01:35 UTC, Honey wrote:
> On Monday, 19 June 2017 at 20:26:43 UTC, Adam D. Ruppe wrote:
>> On Monday, 19 June 2017 at 20:20:23 UTC, Honey wrote:
>>> Is it correct that D produces executables that depend on libc?
>>
>> Usually yes, since that makes sense for most programs on 
>> operating systems, but you can pull it out if you want to for 
>> a specialized task. (Really, same boat C is in.)
>
> Thanks, Adam!
>
> To elaborate on my second point: if one compares, say, 
> FreeBSD's libc [1] with glibc [2] it is pretty obvious that not 
> all implementations are optimized to the same degree.
>
> Does it make sense - at least in cerain cases - to provide and 
> use a D implementation that is fast on all platforms, instead?
>
> [1] https://svnweb.freebsd.org/base/head/lib/libc/
> [2] https://sourceware.org/git/?p=glibc.git;a=tree;hb=HEAD

The issue with that is that you assume:

1) that a complete libc replacement can be created from scratch
2) that a correct libc replacement can be created from scratch
3) that a better libc replacement can be created from scratch
4) that this replacement can be maintained for years to come on 
all plateforms

All those points are certainly theoretically possible, but 
getting all 4 at once isn't a small task. Point 2 and 3 in 
particular: whatever your libc is it's been tested, reflected 
upon and optimized for years by good programmers. There is 
absolutely no reason to throw away this work. Even if it was 
practical to do that and that the developper was confident enough 
that he can do better than libc to start working on it, point 4 
would be out of reach given the current state of affairs.

So, while replacing specific C functions by D implementations 
where the gain is clear seems like a good idea to me, dropping 
the dependency on libc seems more like a risky gamble than 
anything.