En términos de diseño de lenguaje, en realidad no hay nada que deba hacer que Go sea más lento que Java en general. De hecho, le brinda un mayor control del diseño de memoria de sus estructuras de datos, por lo que para muchas tareas comunes debería ser algo más rápido. Sin embargo, el compilador Go, el planificador, el recolector de basura, la biblioteca regexp y muchas otras cosas principales no están particularmente optimizados. Esto está mejorando constantemente, pero el enfoque parece estar en ser útil, simple y lo suficientemente rápido como para ganar en microbenchmarks.
En el punto de referencia vinculado, Go pierde mucho frente a Java en el árbol binario y la prueba regexp. Esas son pruebas del sistema de administración de memoria y la biblioteca regexp respectivamente. La administración de memoria de Go podría ser más rápida y ciertamente mejorará con el tiempo, y la biblioteca de expresiones regulares estándar actual es un marcador de posición para una implementación mucho mejor que está por venir. Entonces, perder en esos dos no es sorprendente, y en el futuro cercano el margen debería ser más estrecho.
Para el punto de referencia de k-nucleótidos, es algo difícil de comparar porque el código Java parece estar usando un algoritmo diferente. El código Go sin duda se beneficiará de las futuras mejoras del compilador, el planificador y el asignador, incluso tal como está escrito, pero alguien tendría que reescribir el código Go para hacer algo más inteligente si quisiéramos comparar con mayor precisión.
Java gana en el punto de referencia de mandelbrot porque todo es aritmética de punto flotante y bucles, y este es un gran lugar para que la JVM genere un código de máquina realmente bueno y levante cosas en tiempo de ejecución. Go, en comparación, tiene un compilador bastante simple que no levanta, desenrolla ni genera un código de máquina realmente ajustado actualmente, por lo que no es sorprendente que pierda. Sin embargo, uno debe tener en cuenta que el tiempo de Java no cuenta el tiempo de inicio de JVM o las muchas veces que debe ejecutarse para que JVM lo ejecute correctamente. Para programas de larga duración, esto no es relevante, pero es importante en algunos casos.
En cuanto al resto de los puntos de referencia, Java y Go están básicamente unidos, y Go toma significativamente menos memoria y, en la mayoría de los casos, menos código. Entonces, mientras que Go es más lento que Java en varias de esas pruebas, Java es bastante rápido, Go lo hace bastante bien en comparación, y Go probablemente será notablemente más rápido en el futuro cercano.
Estoy deseando que gccgo (un compilador de Go que usa el código de gcc) esté maduro; eso debería hacer que Go esté bastante en línea con C para muchos tipos de código, lo que será interesante.