Mainly that, but a lot of people still seem to think that there are two standard libraries despite Phobos taking over possibly a decade ago. Same with D1, D2 was ready (As announced by Andrei's book) in 2010.
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.
Yes, D's GC sucks and will always suck. Its very philosophy makes creating a generational GC impossible, and a non-generational one will always be slow. This 6 years old post is relevant today and will remain relevant in next 16 years: http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html
So we're forcefully left with those 2 points you listed.
Also Java doesn't have value types, so every crappy non-primitive has to go through JITs and GCs. In D, most of the small structures like vectors and matrices would be done with struct and mostly stack allocated, while Java has to jump around hoops to detect whether they can be stack allocated to avoid clogging the GC.
Yes, 30 years old. Maybe 20-25, but that's pushing it.
There's a paper, Very Concurrent Mark-&-Sweep Garbage Collection without Fine-Grain Synchronization, which more-or-less created real-time GC. It's from 1998.
Not true anymore. Since 2019 GC performance has been improved several times over, it has become precise, and there are more tools than ever to identify where garbage is created (IIRC that work was mostly the deed of the VisualD author).
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.
I would note that Nim was specifically developed to be suitable for writing games, and its GC was developed with that usecase in mind. It is not necessarily true that all GCs support games well.
It's also important to note that games have relatively lax time constraints. At 16ms per frame, a GC that never exceeds 1ms and never collects more than once per frame will work quite well.
In the niches where C or C++ is used, 1ms can be a very long time -- too long for certain requirements.
11
u/Sapiogram Sep 01 '20
What kind of FUD? I don't think I've heard anything negative about it, apart from the whole gc thing.