
Falsehoods Programmers Believe about Garbage Collection - mdip
http://paul.bone.id.au/2018/10/19/gc-falsehoods/
======
ncmncm
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.

------
dpc_pw
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.

~~~
ncmncm
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.

~~~
dpc_pw
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.

