What you've said about the JVM overhead is true, but what the experiment showed is that on the time span of six seconds, implementing an algorithm that's this s

What you've said about the JVM overhead is true, but what the experiment showed is that on the time span of six seconds, implementing an algorithm that's this simple, the overhead does not result in the Java solution being slower than the Go solution. Full native code compilation for a hot method can be triggered and completed in a fraction of a second after startup. The net result is that for algorithmic problems that finish in seconds rather than milliseconds, the JVM startup cost may not be an issue. This will only be true if, like this problem, you're loading a small number of classes. Most people's experience with crappy JVM startup time probably has a lot to do with with web application containers like Tomcat that load thousands of classes in the first five seconds. Probably a good test to do to assess real-world performance would be something that does file-system operations and employs some parsing libraries, rather than just building data structures in memory and using System.out. You're correct that if you want to compare peak performance, you should run the tests differently, so that you're not measuring the JVM startup cost.