Been away for a bit. My recap of the recent discussion, in
reverse chronological order...
GC. The discussion on the GC is great, *but* it may be best to
move it to its own thread. I don't think that the nuances of the
GC is a critical issue preventing D becoming adopted at a company
-- even if those nuances (e.g., memory fragmentation,
BlkAttr.NO_SCAN, false pointers, 10 second garbage collection,
room for improvement) are very important to fully grok.
J2EE. Using D instead of J2EE is an interesting notion.
Companies that are invested in using J2EE probably are not
amenable to changing from JVM, so D would be viable for
J2EE-centric enterprise environments if it could be compiled to
Java Bytecode. (The J2EE infrastructure provides a lot of
administration, monitoring, and management facilities.)
Games. As Peter indicated, and I assume Kenta Cho would
whole-heartedly agree, for high-performance games the GC (or even
malloc/free) can be avoided. D is a fully viable language for
high-performance games. Awesome!
License. The discussion on the licenses, as far as I can tell,
impacts several things, and merits having further discussion in
its own thread. Its great to see that D2 compilers are coming
either as stock part of some Linux distros, or as an easily
obtainable package[1].
[1] alas far less great, since the "slight" increase to barrier
to entry is actually quite high. Back before Ruby and Python
were stock components, I've seen people who prefer Python or
prefer Ruby use Perl instead just because they could rely on it
being there -- even though pulling down Python or Ruby was a snap.
Arrays. Thank you for bringing to my attention the GC
implications of using the built-in arrays and slicing. I think
that having D-based template C++ STL/BOOST-like alternatives that
have different (non-GC) memory requirements makes sense now. I
don't think this is a show-stopper for D becoming adopted at a
company.
