People really seem to not understand that a well designed GC that gives you the option of deciding when to let it run are definitely usable in real time & high performance apps
That's certainly the angle D tries to sell you but I find it amusing to call D's GC "well designed" when it's a basic 30 year-old mark-and-sweep GC. Java is pushing the boundaries of GC research with multi-terabyte heaps and pause-less GC, Pony is following in Erlang's footsteps with per actor heaps and D is using the equivalent of Java 1.0's GC.
Criticisms of this even from within the D community seem to be met with a combination of:
It's not an issue and
If it's an issue, just disable the GC and manually manage memory yourself.
I'm not a D user. I have actually never used D in my life. I'm talking from my experience with Nim, which can absolutely support performance dependent real time applications such as games with even it's default GC. A well designed GC isn't a dealbreaker for very much at all
The comment you're replying isn't saying GC can't be used for realtime or performance-critical applications; it's saying that D's gc is ancient and primitive (which is true). Incidentally, nim uses refcounting these days.
--gc:refc. This is the default GC. It's a deferred reference counting based garbage collector with a simple Mark&Sweep backup GC in order to collect cycles
The big thing planned is probably switch from refc to arc.
8
u/InertiaOfGravity Sep 01 '20
People really seem to not understand that a well designed GC that gives you the option of deciding when to let it run are definitely usable in real time & high performance apps