On Monday, 6 June 2016 at 10:54:41 UTC, Guillaume Piolat wrote:
On Monday, 6 June 2016 at 08:18:20 UTC, Russel Winder wrote:
(...)
This should be marketed as a major feature of D: the language
with a GC for those situations where you want it, and manual
memory management for those cases where you do not want a GC.
Having the GC for the UI is very pleasant, while @nogc
time-critical code won't use it.
It think the problem is that the message then become more
complicated.
GC is easily victim of the "holier-than-thou" fallacy, because
evidently less GC is supposed to translate into faster
programs. Er... right?
I'm just worried how usable this approach really is at scale. If
you combine 20 D libraries, 17 of which use GC, are you able to
control the GC well enough for a low-latency app? The problem
with GC is that its a global (per process) resource so it poisons
everything in the program with its unpredictable time
consumption. I would be hesitant to market this without designing
and testing a viable development methodology first. And then
there is reference counting which is another way to be productive
that doesn't have this problem.
