How can D become adopted at my company?

[Eljay]

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.