
Why are garbage collectors so important? - mastrsushi
The real world experience I have in C++ has been embedded driver development. I&#x27;ve never written a program in a binary compiled language large enough to experience major side effects from improper manual memory management.<p>I know that Go, Lisp and many other compiled languages have Garbage Collectors. Why would they choose to, given the performance cost?
======
tlack
My take as a hobbyist in this area:

In highly complex, long running systems, it's very difficult to know
automatically when memory is no longer needed.

Reference counting, and its draconian creepy uncle malloc()/free(), require
programmers to be very careful about when they free memory.

This is a life of tossing in turning in bed: Did you carefully free before you
returned in that error handler?

C++ has the benefit of strict compile time analysis, and a lot of the
confusing bits have sensibly been pushed to the standard container types'
implementations.

Dynamic systems with diverse "types" and millions of collections of objects,
especially ones that are likely to contain "cycles" and references to each
other, often take other approaches that aren't as "match up the alloc() and
free()"-oriented, such as periodically scanning the entire object graph and
deleting stuff that couldn't be reached.

Madness! But runs like hell when the graph is small and most people won't feel
the burn. An ongoing area of research.

------
the_hoser
They're going for a different kind of performance. Memory safety eliminates
entire classes of problems, freeing the programmer to focus on other things.
For the vast majority of software projects, the performance is more than
adequate, and the benefits are well worth the costs.

