Smart pointers instead of GC?

[Don]

On Tuesday, 4 February 2014 at 10:32:26 UTC, ed wrote:
> On Tuesday, 4 February 2014 at 09:59:07 UTC, Don wrote:
>> On Tuesday, 4 February 2014 at 03:43:53 UTC, ed wrote:
>>> On Tuesday, 4 February 2014 at 01:36:09 UTC, Adam Wilson 
>>> wrote:
>>>> On Mon, 03 Feb 2014 17:04:08 -0800, Manu 
>>>> <turkeyman at gmail.com> wrote:
>>>>
>>>>> On 4 February 2014 06:21, Adam Wilson <flyboynw at gmail.com> 
>>>>> wrote:
>>>>>
>>>>>> On Mon, 03 Feb 2014 12:02:29 -0800, Andrei Alexandrescu <
>>>>>> SeeWebsiteForEmail at erdani.org> wrote:
>>>>>>
>>>>>> On 2/3/14, 6:57 AM, Frank Bauer wrote:
>>>>>>>
>>>>>>>> Anyone asking for the addition of ARC or owning pointers 
>>>>>>>> to D, gets
>>>>>>>> pretty much ignored. The topic is "Smart pointers 
>>>>>>>> instead of GC?",
>>>>>>>> remember? People here seem to be more interested in 
>>>>>>>> diverting to
>>>>>>>> nullable, scope and GC optimization. Telling, indeed.
>>>>>>>>
>>>>>>>
>>>>>>> I thought I made it clear that GC avoidance (which 
>>>>>>> includes considering
>>>>>>> built-in reference counting) is a major focus of 2014.
>>>>>>>
>>>>>>> Andrei
>>>>>>>
>>>>>>>
>>>>>> Andrei, I am sorry to report that anything other than 
>>>>>> complete removal of
>>>>>> the GC and replacement with compiler generated ARC will be 
>>>>>> unacceptable to
>>>>>> a certain, highly vocal, subset of D users. No arguments 
>>>>>> can be made to
>>>>>> otherwise, regardless of validity. As far as they are 
>>>>>> concerned the
>>>>>> discussion of ARC vs. GC is closed and decided. ARC is the 
>>>>>> only path
>>>>>> forward to the bright and glorious future of D. ARC most 
>>>>>> efficiently solves
>>>>>> all memory management problems ever encountered. 
>>>>>> Peer-Reviewed Research and
>>>>>> the Scientific Method be damned! ALL HAIL ARC!
>>
>>>
>>> Most of us know and understand the issues with ARC and that 
>>> with a GC. Many of us have seen how they play out in systems 
>>> level development. There is a good reason all serious driver 
>>> and embedded development is done in C/C++.
>>>
>>> A language is the compiler+std as one unit. If Phobos depends 
>>> on the GC, D depends on the GC. If Phobos isn't systems level 
>>> ready, D isn't systems level ready. I've heard arguments here 
>>> that you can turn off the GC, but that equates to rewriting 
>>> functions that already exists in Phobos and not using any 
>>> third-party library.
>>
>> At Sociomantic, that is exactly what we have done. Phobos is 
>> almost completely unusable at the present time.
>>
>> I personally don't think that ARC would make much difference. 
>> The problem is that *far* too much garbage is being created. 
>> And it's completely unnecessary in most cases.
>>
>> To take an extreme example, even a pauseless, perfect GC, 
>> wouldn't make std.json acceptable.
>>
>>
>>> Why would anyone seriously consider that as an option? 
>>> Embedded C++ has std:: and third-party libraries where memory 
>>> is under control?
>>>
>>> Realistically D as a systems language isn't even at the hobby 
>>> stage.
>>
>> We're using D as a systems language on a global commercial 
>> scale. And no, we don't use malloc/free. We just don't use 
>> Phobos.
>
> Maybe I'm thinking too much embedded, which I admit isn't fair 
> on D and at this stage maybe not a realistic comparison.

Yeah, I dunno what "systems language" means really. In practice 
it seems to mean "competes with C++" and that's how I use it. And 
C++ had some problems getting into the embedded market.

Though even D as "a better C" is a surprisingly nice language.


> Our projects are Siemens medical devices so it is 90% embedded, 
> a different level of system perhaps. They too would be on a 
> global scale and I'd love to get D on them :-)

Yeah. I can imagine that's a tough assignment.