On Mon, 12 Dec 2011 10:00:28 -0500, Timon Gehr <timon.g...@gmx.ch> wrote:
On 12/12/2011 03:00 PM, Steven Schveighoffer wrote:
On Sun, 11 Dec 2011 16:17:20 -0500, Timon Gehr <timon.g...@gmx.ch>
wrote:
On 12/11/2011 10:12 PM, Timon Gehr wrote:
On 12/11/2011 06:49 PM, Paulo Pinto wrote:
Am 11.12.2011 17:40, schrieb so:
On Sun, 11 Dec 2011 18:33:07 +0200, Paulo Pinto
<pj...@progtools.org>
wrote:
Really?
Tell that to all game studios developing games in Java/C#/Flash.
Do you know that many games in iPhone are done in Unity, which
makes use of C#/Boo/Javascript compiled to native code?
I don't understand sorry, are you arguing against the argument i
made on
GCs failure on some specific areas?
Yes I am, since I know many areas where GC enabled languages have
been
replacing non-GC languages for better or worse.
But then again, I am only a lurker here, so take my arguments with a
grain of salt.
As a non user of D, I cannot really say much.
GC does not scale if an application has to be responsive. In all other
cases it is a valid choice.
(if you have enough spare memory)
Don't confuse druntime's GC with the concept of a GC. Better implemented
GCs work quite well in practice, even for making responsive apps.
I certainly don't confuse them (GC wouldn't be very interesting if the
two were the same), and as I understand it there exist very few GC
implementations that _guarantee_ responsiveness over a long time period.
This effect gets a lot bigger as memory usage and reference mutation
rate grow. It is very easy for a sufficiently big Java application, for
instance, to get responsiveness problems.
Oh, I've seen it first hand, I use netbeans.
But I'm not sure it's due to the GC, and not due to it requiring 2x or
more memory than an equivalent manually managed application requires. I
honestly don't konw.
Generally bad things happen when memory gets low, no matter what the
memory management system or language.
-Steve