What you&#x27;re saying could be taken two ways.<p>1. That the time (including start-up time) for something on the JVM would be longer because the JVM needs to start up.<p>2. That Go producing a native binary is automatically faster at things.<p>In reference to the first, the benchmark timings are started when the software actually starts running.<p>In terms of the second, being a native binary doesn&#x27;t mean faster.  Go still has a runtime.  It&#x27;s just included in the binary.<p>Go&#x27;s performance advantage is probably a few things.  Go was made to spawn millions of goroutines and Go uses primitive types.  I don&#x27;t know all that much about Scala, but I believe it doesn&#x27;t do primitive types which means that every one of those Int objects requires following a pointer to get to the value.  That&#x27;s overhead.  EDIT: this looks like it&#x27;s wrong as Scala has a bunch of pre-defined classes that extend AnyVal and correspond to primitive types in Java.<p>It also looks like the Scala code is passing back a Long even when the value is still small enough to fit in an Int.  That&#x27;s doubling the amount of memory when that memory only needs 64-bits near the end stages.  By contrast, the Go code does `sum := 0` which I&#x27;m not actually sure how that&#x27;s working.  If I initialize a 32 bit int without specifying it, I see that I wrap around (<a href="http:&#x2F;&#x2F;play.golang.org&#x2F;p&#x2F;PiiMZmEzKp" rel="nofollow">http:&#x2F;&#x2F;play.golang.org&#x2F;p&#x2F;PiiMZmEzKp</a>).  So, I&#x27;m not sure how initialising it to 0 and then adding to something over an int32 works.  Maybe Go uses a different default int depending on platform?<p>Go&#x27;s implementation is also simpler.  In the Scala version, there&#x27;s a receive method and the sub-actors just pass back when they&#x27;re done potentially causing a bunch of switching.  Go, on the other hand, creates all the goroutines and only when that&#x27;s done starts receiving from them.  In the Scala version, the program might think that there&#x27;s value in switching from creating the sub-actors to receiving from them - and they should pass back very quickly.  The implementation here in Go doesn&#x27;t allow for that switching.<p>When dealing with something as synthetic as this, all of these little things matter.