On Wed, Jan 13, 2021 at 06:58:56PM +0000, Marcone via Digitalmars-d-learn wrote: > I've always heard programmers complain about Garbage Collector GC. But > I never understood why they complain. What's bad about GC?
It's not merely a technical issue, but also a historical and sociological one. The perception of many people, esp. those with C/C++ background, is heavily colored by the GC shipped with early versions of Java, which was stop-the-world, inefficient, and associated with random GUI freezes and jerky animations. This initial bad impression continues to persist today esp. among the C/C++ crowd, despite GC technology having made great advances since those early Java days. Aside from skewed impressions, there's still these potential concerns with the GC: (1) Stop-the-world GC pauses (no longer a problem with modern generational collectors, but still applies to D's GC); (2) Non-deterministic destruction of objects (D's dtors are not even guaranteed to run if it's a GC'd object) -- you cannot predict when an object will be collected; (3) GC generally needs more memory than the equivalent manual memory management system. (1) and (2) can be mitigated in D in various ways, e.g., prefer structs over classes to reduce GC load, use GC.stop, GC.collect to control when collections happen, etc.. Use RAII structs or scope guards for things that need deterministic destruction. (Or use malloc/free yourself.) (3) is generally not a big problem unless you're targeting low-memory devices, in which case you already have to do many things manually anyway, so you generally won't be relying on the GC in the first place. There's also the matter of ROI: it's *much* easier, and faster, to write GC code than code with manual memory management. For 90% of software, none of the above concerns matter anyway, and you're just wasting your time/energy for essentially no benefit (and lots of disadvantages, like wasting time/energy debugging hard-to-trace pointer bugs and subtle memory corruptions). GC code also tends to be cleaner: your APIs don't have to be polluted with memory-management paraphrenalia that tend to percolate all over your code and make it hard to read and harder to maintain. You get to focus your mental resources on making actual progress in your problem domain instead of grappling with memory management issues at every turn. And most of the time, it's Good Enough(tm); the customer won't even notice a difference. The price of using a GC is far dwarved by the benefits it brings. Without a GC you're pouring down blood and sweat just to make a little progress in your problem domain, and the whole time you're plagued with pointer bugs, memory corruptions, and all sorts of lovely issues that come with just one tiny mistake in your code but takes hours, days, or even months to fix. And your code will be convoluted, your API's ugly, fragile, and hard to maintain. The ROI simply makes no sense, except for very narrow niches like hard real-time software (where a patient may die if you get an unexpected GC pause while controlling a radiation treatment device) and game engine cores. But there is no convincing a hard-core GC hater sometimes. You do so at your own risk. :-D T -- Life begins when you can spend your spare time programming instead of watching television. -- Cal Keegan
