A betterC base

[Rubn]

On Friday, 9 February 2018 at 02:09:57 UTC, Jonathan M Davis 
wrote:
> On Thursday, February 08, 2018 23:57:45 Rubn via Digitalmars-d 
> wrote:
>> On Thursday, 8 February 2018 at 18:06:38 UTC, Walter Bright 
>> wrote:
>> > I.e. it isn't an issue of us D guys being dumb about the GC.
>>
>> So you could say it's a design flaw of D, attempting to use a 
>> GC where it isn't suited?
>
> You could say that, but many of us would not agree. Just 
> because certain classes of GCs cannot be used with D does not 
> mean that the fact that D has a GC built-in is not beneficial 
> and ultimately a good design decision. Plenty of folks have 
> been able to write very efficient code that uses D's GC. 
> Obviously, there are use cases where it's better to avoid the 
> GC, but for your average D program, the GC has been a fantastic 
> asset.
>
> - Jonathan M Davis

I didn't say that a GC isn't beneficial, the problem is if you 
are going to be using the GC there are plenty of other languages 
that implement it better. The language is designed around the GC. 
Anytime I try and use an associative array, my program crashes 
because of the GC. The workaround I need to do is just make every 
associative array static. Maybe if phobos could be built into a 
shared library it wouldn't be as big of a problem. But that's not 
the case, before someone goes around crying that Phobos CAN be 
built into a shared library, remember platform matters!

You can write efficient code with Java, and that has an entire VM 
running between the cpu and the language. Efficiency isn't the 
issue. Writing code that is both GC and non-GC code is extremely 
difficult to do correctly. That it just isn't worth it at the end 
of the day, it complicates everything, and that is the design 
flaw. Having to use a complicated inefficient GC is just a side 
effect of the greater issue.