ESR "Waning of Python" post

[Marko Rauhamaa]

Paul Rubin <no.email at nospam.invalid>:
> Note that Java has a lot of [GC] options to choose from:
> https://docs.oracle.com/javase/9/gctuning/available-collectors.htm

I'm all for GC, but Java's GC tuning options are the strongest
counter-argument against it. The options just shift the blame from the
programming language to the operator of the software.

For GC to be acceptable, you shouldn't ever have to tune it. And I've
seen it in action. A customer complains about bad performance. The
system engineer makes a tailored GC recipe to address the issue, which
may help for a short while.

Here's my rule of thumb. Calculate how much memory you need for
long-term objects. Don't let the application exceed that amount.
Multiply the amount by 10 and allocate that much RAM for your
application.

> Another approach is Erlang's, where the application is split into a
> lot of small lightweight processes, each of which has its own GC and
> heap. So while some of them are GC'ing, the rest can keep running.

So the lightweight processes don't share any data. That may be a fine
approach.


Marko