Erlang Garbage Collection Details and Why They Matter

I would expect this kind of article to start with numbers showing that Erlang&#x27;s GC has shorter GC pauses than, say, Java or Go and then explain why this is so.<p>Instead it merely states that Erlang GC has better latency than other system and we&#x27;re supposed to just believe it.<p>It&#x27;s fine as a description of how Erlang GC works but totally useless as an argument that Erlang has short GC pauses.

How much of this is truly &quot;Erlang&quot; 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?

I enoyed this [unexpectedly] informative read right up until the conclusion:<p><pre><code> 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 &quot;If you must read the rest of this document to understand the behavior of your program, you are being too clever. Don&#x27;t be clever.&quot;, I believe that we must be clever enough to make our system faster and safer, and sometimes it doesn&#x27;t happen unless we dig deeper into what is going on. </code></pre> 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..<p>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.<p>While I may personally appreciate Go&#x27;s opinionated-ness, it seems to lead to excessive amounts of conflict and drama. I wonder if it&#x27;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.<p>Food for thought.<p>TLDR: It looks rather silly to compare languages with very different design goals.

&gt; Unlike Go Language Memory Model Documentation Page that advices &quot;If you must read the rest of this document to understand the behavior of your program, you are being too clever. Don&#x27;t be clever.&quot;<p>I see a language barrier here. (no pun intended)