D Language 2.0

[Andrei Alexandrescu]

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