Incorporating D

[H. S. Teoh]

On Fri, Jan 25, 2013 at 02:53:31PM -0800, Walter Bright wrote:
[...]
> If you stick to bread and butter code, you shouldn't have problems.
> If you use advanced features out to the edge, you're more likely to
> run into issues.

And I have to add that so far, I haven't found any problems that are
showstoppers (in the sense that there's no way to work around it).
Almost all of the bugs I've found have workarounds that aren't too
painful. (They may look a bit ugly at times, but they work, and let you
get the job done.)

Even with advanced features, when you run into bugs it's almost always
possible to recast your code in a way that *doesn't* use that specific
combination of advanced features that exhibit the bug. You may not be
able to write idealistic, perfect code in that case, but things will
still work.


[...]
> >Is it true that D has GC problems?
> 
> All GC's have problems. GC isn't a "fire and forget" way to deal
> with memory management. However, the GC is reliable and works well
> if you use it with awareness of how it works.
[...]

I have to say that while the current GC certainly could do with some
significant improvements, *I've* certainly never run into any major
problems with it yet.

There have been reports of performance loss in some cases, but there are
ways to disable/re-enable the GC which you can use to minimize the
problem around critical pieces of code.

In any case, the GC *is* being worked on, and hopefully we'll see a much
better incarnation of it in the near future.

(Not to mention that having a GC makes it much easier to write certain
kinds of code. Complex string manipulations, for example, are an utter
pain in the neck in C/C++. The simplest operations require meticulous
care and copious tricky pointer arithmetics to prevent buffer overflows
and memory leaks. In D, you just write string operations with impunity
and they Just Work(tm). And the resulting code is much more readable.)


T

-- 
Your inconsistency is the only consistent thing about you! -- KD