Am 08.01.2013 16:25, schrieb H. S. Teoh:
On Tue, Jan 08, 2013 at 10:29:26AM +0100, Paulo Pinto wrote:
On Monday, 7 January 2013 at 23:13:13 UTC, H. S. Teoh wrote:
...
Crippling the language to cater to the 10% crowd who want to squeeze
every last drop of performance from the hardware is the wrong
approach IMO.
[...]
Agreed.
Having used GC languages for the last decade, I think the cases
where manual memory management is really required are very few.
Even if one is forced to do manual memory management over GC, it is
still better to have the GC around than do everything manually.
Yes, hence my idea of splitting up the performance-critical core of a
game engine vs. the higher-level application stuff (like scripting,
etc.) that aren't as performance-critical. The latter would be greatly
helped by a GC -- it makes it easier for scripting people to use,
whereas writing GC-less code demands a certain level of rigor and
certainly requires more effort and care than is necessary for the most
part.
But this is based on my experience doing business applications,
desktop and server side or services/daemons.
[...]
Well, business applications and server-side stuff (I assume it's
web-based stuff) are exactly the kind of applications that benefit the
most from a GC. In my mind, they are just modern incarnations of batch
processing applications, where instant response isn't critical, and so
the occasional GC pause is acceptable and, indeed, mostly unnoticeable.
Besides Web applications, I also took part in projects that ported high
performance C++ daemons to Java.
These were servers doing millions of data processing manipulations per
second of telecommunication data used in mobile networks.
In a famous Finn/German telecommunications company lots of server code
has been migrated from C++ to Java in the last years.
--
Paulo
