Go does not need a Java-style GC
The binary-trees benchmark on The Debian Language Shootout[1] involves allocating millions of short-lived trees and traversing them. It is informative about GC performance even with the caveat that there are &#x27;lies, damned lies, and benchmarks&#x27;, because many real-world graph analysis and brute force tree search algorithms similarly allocate zillions of short-lived nodes. For non-GC languages like C&#x2F;C++&#x2F;Rust it gives a decent idea of the performance difference between malloc&#x27;ing and freeing individual objects vs doing bulk arena allocations:<p><pre><code>  language         secs       GC&#x27;d language?
  ========         ====       ==============
  C++ (g++)        0.94
  Rust             1.09
  C (gcc)          1.54
  Free Pascal      1.99
  Intel Fortran    2.38
  Java             2.48       yes  &lt;====
  Lisp (SBCL)      2.84       yes
  Ada (GNAT)       3.12
  OCaml            4.68       yes
  Racket           4.81       yes
  C# .NET          4.81       yes
  Haskell (GHC)    5.02       yes
  Erlang           5.19       yes
  F# .NET          6.06       yes
  Node.js          7.20       yes
  Julia            7.43       yes
  Chapel           7.96       yes
  Dart             9.90       yes
  Go              12.23       yes  &lt;====
  Swift           16.15       * &quot;Automatic Reference Counting&quot;
  Smalltalk (VW)  16.33       yes
  PHP             18.64       yes
  Ruby            23.80       yes
  Python 3        48.03       yes
  Lua             48.15       yes
  Perl            53.02       yes
</code></pre>
So Java has the fastest GC for this test, 2.48 secs vs 12.23 secs for Golang. The Java code is also notably perfectly idiomatic for multicore, it doesn&#x27;t do heroic &quot;avoid GC by writing C-like code manipulating a fixed global memory array&quot; tricks. The Java code is also more concise.<p>The &#x27;plain C&#x27; code that uses Apache Portable Runtime memory pools instead of standard malloc&#x2F;free and uses OpenMP #pragma&#x27;s strikes me as more &#x27;heroic&#x27; than &#x27;idiomatic&#x27;, whereas C++ and Rust use standard libraries&#x2F;crates and idiomatic patterns. (Note that OpenMP is &#x27;standard&#x27; for high-performance C and well supported across GCC&#x2F;LLVM&#x2F;Microsoft&#x2F;Intel compilers. But still....)<p>OCaml and Haskell made impressive showings for functional languages which are in practice the easiest for dealing with complicated tree algorithms, which is perhaps why the formally verified C compiler, CompCert, is implemented in OCaml, as is Frama-C for formally verifying ISO C programs, as is the Coq theorem prover, etc.<p>[1] <a href="https:&#x2F;&#x2F;benchmarksgame-team.pages.debian.net&#x2F;benchmarksgame&#x2F;performance&#x2F;binarytrees.html" rel="nofollow">https:&#x2F;&#x2F;benchmarksgame-team.pages.debian.net&#x2F;benchmarksgame&#x2F;...</a>
[Edited link]