There are still plenty of truths that make sweepy GC a terrible basis for a general purpose programming language.
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.
GC is like Socialism. The theory is that it's going to be all wonderful, yet every time it is actually implemented it sucks, and you typically have to fight problems that don't exist in other systems.
Socialized medicine has been working out super great for most of the world for long enough to know it is a great idea worth copying. Meanwhile, infant mortality in the US is on par with, what, Belarus? Oops, no, Belarus is doing quite a lot better now.
Socialized road maintenance is still working out pretty well, even in the US. We were doing pretty well with drinking water, most places, until recently, although corporate influence delayed improvements in lead- and mercury-exposure standards by many decades.
Analogies don't always work out the way we would like.
Cherry-picked examples are not invalidating my analogy. :P
American healthcare is broken for reasons other than free market/capitalism. And I actually come from Poland, and experience first-hand how socialized medicine sucks,a and see how left-leaning Americans love to glorify and ignore problems with public health care, which actually sucks in practice, just a bit less than then oligopolic, corporate, overregulated model from USA.
I don't want to argue more about healthcare. My analogy is quite accurate.
Critics of manual-memory management will always bring up totally broken C model: how insecure it is, tedious etc. and compare it with a decent example of heavy, complex automatic model: Java GC, and ignore whole bunch of problems with Java GC that one experience in practice, that are fundamentally unfixable. The best way is actually a modern, lightweight manual-memory model like in Rust.
Just like the best health-care model would be a private, lightweight, competitive market, with just the right (small) amount of government tuning and incentives.
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.