
Erlang Garbage Collection Details and Why They Matter - byaruhaf
https://hamidreza-s.github.io/erlang%20garbage%20collection%20memory%20layout%20soft%20realtime/2015/08/24/erlang-garbage-collection-details-and-why-it-matters.html
======
kjksf
I would expect this kind of article to start with numbers showing that
Erlang's GC has shorter GC pauses than, say, Java or Go and then explain why
this is so.

Instead it merely states that Erlang GC has better latency than other system
and we're supposed to just believe it.

It's fine as a description of how Erlang GC works but totally useless as an
argument that Erlang has short GC pauses.

~~~
oomkiller
Here is a semi-recent benchmark for Phoenix, which is written in Elixir (runs
on the Erlang VM, BEAM). I think it will give you a decent idea of the
differences:
[https://gist.github.com/omnibs/e5e72b31e6bd25caf39a](https://gist.github.com/omnibs/e5e72b31e6bd25caf39a)

I would like to see this run with the latest versions of the various
platforms, as a lot has changed since Phoenix 0.13, and I'm sure it has for
the other platforms that were benchmarked as well. Initially, it seems like
there is not a lot of difference between most of the platforms, but when
you're working with variances of 1-2 ms on 180k rps is pretty substantial.

~~~
kenOfYugen
Would it be possible to update node.js to v4.0.0 and rerun the Express Cluster
benchmark? node.js v0.12.x was slower than v.0.10.x, while v4.0.0 is supposed
to be faster than both. Sorry for making this request if it's out of your
field of interest, but couldn't resist asking :)

EDIT: My mistake, I thought you were the author of the benchmark

------
joosters
How much of this is truly "Erlang" GC and how much just happens to be the
current implementation found in Erlang? Does Erlang the language specify that
this is how the GC acts, or is the language free to use whatever GC
implementation it likes? iN short, if you are writing in Erlang, can you be
certain that the GC will always act in the manner described?

~~~
hajile
Erlang basically has BEAM which is similar to Cpython or YARV in that it is
both the official implementation and de-facto standard because the actual
standards are either non-existent or don't cover a lot of edge cases (making
an unofficial spec).

That said, I believe that if an official third-party specification for Erlang
were ever created, it would likely have to specify a similar GC and threading
system because this is necessary to allow the normal Erlang programming style.

------
jaytaylor
I enoyed this [unexpectedly] informative read right up until the conclusion:

    
    
        Even if we are using a language that manages memory itself
        like Erlang, nothing prevents us from understanding how memory
        is allocated and deallocated. Unlike Go Language Memory Model
        Documentation Page that advices "If you must read the rest of
        this document to understand the behavior of your program, you
        are being too clever. Don't be clever.", I believe that we must
        be clever enough to make our system faster and safer, and
        sometimes it doesn't happen unless we dig deeper into what is
        going on.
    

The potshot at Go in the conclusion seems counter-productive. The author is
certainly taking the quote in a different spirit than it was intended..

Erlang and Go have functional overlap, sure. However the trade-offs between
both the guarantees and operational realities of the two languages leaves each
one best suited to a different domain. Thus it is a pointless waste of time to
argue and criticize one or the other in this manner.

While I may personally appreciate Go's opinionated-ness, it seems to lead to
excessive amounts of conflict and drama. I wonder if it's an overall win or
loss. On one hand, the controversy sparks interest which helps spread Go. On
the other hand, it alienates many folks who may otherwise be open to getting
involved.

Food for thought.

TLDR: It looks rather silly to compare languages with very different design
goals.

~~~
zamalek
The advice goes somewhat deeper than this. Design goals aside you really
shouldn't get too clever with GCs as they are _subject to change._ If the GC
changes (because of platform upgrades, or simply using different runtimes)
suddenly your application can start showing strange or bad memory performance
characteristics.

Either way a less controversial way to put the Go advice would be:

> If you must read the rest of this document to understand the behavior of
> your program, you are being untrusting. Don't use things you don't trust.

If you care about memory performance characteristics that much you really
should be using a language that gives you control over them.

 _That 's not to say that all GC advice is bad: good GC advice exists and
usually sticks to the formal definition of a GC (an infinite memory
simulator), instead of implementation details which, again, can change._

~~~
shepardrtc
Then why don't they just say that? Something like, "Hey, we may change how
this works in the future. Clever optimizations now may not work down the
road."

~~~
zamalek
The problem with depending on specific optimizations like that it lock-steps
you to updates that boast improvements (that break your implementation-
dependant code).

------
halayli
> Unlike Go Language Memory Model Documentation Page that advices "If you must
> read the rest of this document to understand the behavior of your program,
> you are being too clever. Don't be clever."

I see a language barrier here. (no pun intended)

