• The garbage collector eliminates probably 60% of potential users right off.

If we rename garbage collection to "automatic memory leak detection and cleanup." For people who write realtime applications, that's what it is. D is garbage collected in the sense that it's available as an option.

As noted in another thread:

If we rename garbage collection to "automatic memory leak detection and cleanup." For people who write realtime applications, that's what it is. D is garbage collected in the sense that it's available as an option.

Walter noted that with 20+ years of experience writing manually managed code, he still could not write leak-free programs.

I propose:

• Rename GC to automatic memory leak detection and cleanup in documentation
• Make core.memory.__delete a better name. Perhaps core.memory.free.
• Runtime should have an option to emit a warning every time an object is cleaned up on the major heap. There should be a compiler or runtime option that attaches debug information so we stack trace of the allocation. Optionally, this could be enabled for certain classes via a UDA.
• If possible, a compiler and/or runtime option to safely detect and warn on double-frees. That way, we can boast being memory-safe.

As someone who writes a realtime, major-GC-is-not-allowed JavaScript game, having the stack trace of where an object is leaked helps fixing garbage generation greatly.

Lockheed Martin reviewed various options for the Aegis Open Architecture including the programming language and execution environment for the system. In their experiments, they found that HotSpot Java code ran comparable to C++ on an experimental 250 millisecond periodic workload. At the same time, they found that the Java language provided superior abstraction and encapsulation than C++, and they judged that retraining their existing staff of CMS-2 programmers to become effective in Java would have lower risks than attempting to train them in C++.
.....
Using Java and PTC Perc Ultra, Lockheed found that newly trained Aegis software engineers implemented a core component, the Aegis Air Defense Warfare (ADW) software, consisting of 150,000 source lines of code, in only 18 months, including test and evaluation and full requirements verification. The first deployment based on the new Aegis Open Architecture required only three years from hardware selection to on-ship hardware refresh, compared to seven years or longer previously.
....
After completing the Aegis Open Architecture refresh, support was added for the new “Standard Missile 6” with only 3 additional months of development effort. Based on experiences with the legacy Aegis implementation, Lockheed would have expected a minimum of a full year of additional development to add support for a new missile.
Obviously a notable success, Aegis, powered by PTC Perc is now deployed on numerous U.S. ships and those of allied nations. The program has also been expanded beyond shipboard deployment to land-based installations called Aegis Ashore.

People that care about safety and real time GC don't need renaming to be convinced,

Naturally that won't change the mind of the anti-GC folks.

On Tuesday, 13 April 2021 at 11:41:05 UTC, Paulo Pinto wrote:

Your article seems to speak of people actually using the GC so they can speed up development. My game, written in JavaScript, a garbage-collected language, uses pooling. Pooling is the equivalent to manual deallocation. Without pooling the freezes are unbearable. From the performance envelope of my game, a GC gives the strength of an emergency cleanup system and leak detector.

The idea is to emphasize the GC can be completely disabled.

As noted in another thread:

If we rename garbage collection to "automatic memory leak detection and cleanup." For people who write realtime applications, that's what it is. D is garbage collected in the sense that it's available as an option.