C's Biggest Mistake on Hacker News

Seb seb at wilzba.ch
Thu Jul 26 07:18:39 UTC 2018


On Wednesday, 25 July 2018 at 17:23:40 UTC, Ecstatic Coder wrote:
> On Wednesday, 25 July 2018 at 16:39:51 UTC, bpr wrote:
>> On Tuesday, 24 July 2018 at 17:24:41 UTC, Seb wrote:
>>> On Tuesday, 24 July 2018 at 17:14:53 UTC, Chris M. wrote:
>>>> On Tuesday, 24 July 2018 at 16:15:52 UTC, bpr wrote:
>>>>> On Tuesday, 24 July 2018 at 14:07:43 UTC, Ecstatic Coder 
>>>>> wrote:
>>>>>> [...]
>>>>>
>>>>> No. For many C++ users, tracing GC is absolutely not an 
>>>>> option. And, if it were, D's GC is not a shining example of 
>>>>> a good GC. It's not even precise, and I would bet that it 
>>>>> never will be. If I'm able to tolerate a GC, there are 
>>>>> languages with much better GCs than the D one, like Go and 
>>>>> Java.
>>>>>
>>>>> [...]
>>>>
>>>> There was a precise GC in the works at one point, no clue 
>>>> what happened to it.
>>>
>>> The newest PR is:
>>>
>>> https://github.com/dlang/druntime/pull/1977
>>>
>>> Though there's already a bit of precise scanning on Windows, 
>>> e.g. https://github.com/dlang/druntime/pull/1798 and IIRC 
>>> Visual D uses a precise GC too.
>>
>> Well, this is a big problem with D IMO. There are a lot of 
>> unfinished, half baked features which linger in development 
>> for years. How long for precise GC now, over 5 years? I don't 
>> think D was really designed to be friendly to GC, and it just 
>> isn't realistic to expect that there will *ever* be a 
>> production quality precise GC for all of D. Maybe giving up on 
>> some things and finishing/fixing others would be a better 
>> strategy? I think so, which is why I think DasBetterC is the 
>> most appealing thing I've seen in D lately.
>
> +1
>
> But don't be too optimistic about BetterC...
>
> Honestly, considering D's leadership current priorities, I 
> don't see how it could become soon a true C++ or Go competitor, 
> even with the half-baked BetterC initiative...
>
> For instance, I've suggested they consider using reference 
> counting as an alternative default memory management scheme, 
> and add it to the lists of scolarship and crowdsourced project, 
> and of course they have added all the other suggestion, but not 
> this one. What a surprise ;)

The scholarship list is an idea list that is 
community-maintained. Let me quote Mike:

"Thanks to everyone for the project ideas, but I put the list on 
the Wiki for a reason. I'm always pressed for time, so if you 
have an idea for a project suggestion, it would help me 
tremendously if you can just summarize it on the Wiki rather than 
here."

The crowdsourced project was an experiment and the most popular 
item of the state of D survey that had someone who could be 
contacted and was more than willing to work for a scholarship 
salary, was picked.

As Mike has already announced in the blog, it wasn't known before 
that essentially only one goal could be selected.
In the future, it will be possible to select the project(s) you 
are most interested in when donating.

> Despite this is probably one of the most used allocation 
> management scheme in typical C++ development, as this 
> drastically reduces the risks of memory leaks and dangling 
> pointers...

Agreed, but it's easily implemented in a library like RefCounted 
(automem has good implementation too: 
https://github.com/atilaneves/automem).
For example, std.stdio.File is reference-counted ;-)

core.rc will come, but at the moment only Martin is planning to 
work on it and he's busy with a lot of other things (e.g. the 
release process, maintaining the project tester, migrating 
code.dlang.org to a highly-available cluster, fixing DMD 
regressions, ...)

It's the same story as always, just from complaining, things 
won't get magically better... (though it would be great if the 
world worked that way because then maybe my relationships would 
be more successful :O)


More information about the Digitalmars-d mailing list