Leandro Lucarella wrote:
Craig Black, el 19 de enero a las 17:27 me escribiste:
"Leandro Lucarella" <llu...@gmail.com> wrote in message
news:20100119173057.gd14...@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

Reply via email to