Falsehoods Programmers Believe about Garbage Collection

RC -- reference-counting -- is, of course, a kind of GC, and thus another thing to avoid, most of the time, in performant programs. That is a reason "shared_ptr" in C++, and its analog in Rust, are used sparingly, particularly in libraries that might need to be used nobody-knows-where. (Shared_ptr-happy coding is a marker of the reluctant Java convert.) Another reason is that it tends to serialize otherwise parallel programs.

Libraries are at the core of the GC problem. When you control the main program, you can take all kinds of liberties. But a language that doesn't support using the full power of the language to write universally-usable libraries will always remain in whichever ghetto birthed it.

Another problem not noted in the article is the often very poor cache locality behavior of GC-dependent languages. This can often be mitigated by trading off some other desirable quality. Again, such tradeoffs are easy in a main program, and near impossible in a library. Manipulating this tradeoff is characteristic of misleading benchmarks showing GC languages as "nearly as fast as", usually, C. (C++ and Rust are substantially faster than C, in real programs, so are less popular comparison targets.)

Another problem with programs in GC-dependent languages, not mentioned, is what might be called poor citizenship. A GC program might run well when it (a benchmark?) is the only program running, but run several and things may change. This is a consequence of two facts. First, letting garbage accumulate is more efficient for any single program, but may interfere with other programs that would like to do the same. Second, on typical platforms, it is hard to know how much garbage is too much. Memory is cheaper than it once was, most places, but cache is still dear, and an increasing ratio still has baleful consequences.

Many, perhaps most programs need to manage resources other than memory, or even manage more than one kind of memory. Once you have facilities in place to manage any resource, memory is just one of them, and may be managed the same way. When you are blessed with destructors (or a Drop trait), the appeal of GC, or any second system, and its interactions with the first, evaporates.

GC-dependent languages suffer from other problems, but this comment is growing long, and these are enough for me. Not all programs need to be fast, or constructible from mature, widely usable and widely sourced libraries, or play well with others, or manage non-memory resources, but many do. The rest can be coded in GC-dependent languages without shame.