D Language 2.0

[Craig Black]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:hj5llq$tqb$1 at digitalmars.com...
> Leandro Lucarella wrote:
>> Craig Black, el 19 de enero a las 17:27 me escribiste:
>>> "Leandro Lucarella" <llucax at gmail.com> wrote in message
>>> news:20100119173057.GD14794 at llucax.com.ar...
>>>> Walter Bright, el 18 de enero a las 14:31 me escribiste:
>>>>>> More seriously, I don't expect D to see much usage in the embedded
>>>>>> market unless it becomes a huge success on the PC first (if then).
>>>>>> But nothing you can do on the technical front will change that: it's
>>>>>> mostly due to prejudice and preconceptions, not an actual
>>>>>> cost-benefit evaluation of the language.
>>>>> Yeah, I know, I run into the pseudo-problem all the time of D using
>>>>> garbage collection. I point out that you can call/use malloc in D as
>>>>> easily as you can in C++, but it makes no difference. They're
>>>>> convinced that gc will send their app to hell. <g>
>>>>>
>>>>> I fault Java, C#, Python, etc., for some of this anti-gc silliness
>>>>> because those languages make it really hard to use malloc. They just
>>>>> don't believe that malloc is trivial to use in D.
>>>> Well, I think it's a little D's fault too, because several language
>>>> features use the GC (and all the stdlib as well). It's trivial to use
>>>> malloc in D, but, even when it's possible, it's not so easy to 
>>>> completely
>>>> avoid the GC. You just have to be too careful, and I think the features
>>>> that use the GC are not very well documented (same for Phobos).
>>>>
>>>> So I think the GC-will-get-in-the-way fear in D is not totally
>>>> unjustified, even when malloc is trivial to use.
>>> I would have to agree and this is one of my causes for hesisation in
>>> adopting D.  The code I write requires the highest performance
>>> possible.  I am concerned that when I port it over to D, I will have
>>> to avoid using a lot of D features that use the GC (built-in arrays,
>>> closures, standard library features, etc.)  in order to get the best
>>> possible performance.  D does not adhere to the C++ zero-overhead
>>> principle, and I see this as a risk.  So if/when I end up porting my
>>> code to D I may evolve my own dialect of D that uses only the subset
>>> of features that tend to provide the best performance.
>>
>> One thing that can help a lot here is an option for the compiler to avoid
>> compiling stuff that implicitly call the GC (LDC has an option to avoid
>> runtime calls altogether, -noruntime, but maybe that's too extreme). That
>> just helps to avoiding hidden GC usage, you still have to use your own
>> dialect and you probably have to avoid Phobos too.
>
> I'd love -nogc. Then we can think of designing parts of Phobos to work 
> under that regime.
>
> Andrei

That would be great.  Especially if there was a GC-free implementation of 
D's built-in arrays.  Or at the very least a GC-free template for dynamic 
arrays in Phobos.

-Craig