I have found that there can be drastic differences in Go performance in the particular way you structure the program. Writing Go code in a Python-like way is going to be less performant than if you run escape analysis every compile and make deliberate effort to stay on the stack.
> Writing Go code in a Python-like way is going to be less performant than if you run escape analysis every compile and make deliberate effort to stay on the stack.
The fact that people are doing this tedious optimization is strong evidence of the fact that Go needs a generational garbage collector with bump allocation in the nursery.
The JVM has a fast generational GC, and as a result you don't have to do this kind of optimization to get good allocation performance.
See what? This is an unofficial benchmark game - and based on implementations people bothered to provide. Not some scientific test, and nothing that guarantees these are the best implementations. And even if they were they're not representative of server/long running program behavior (where JIT quality and especially GC implementation) matters.
Even so, the page linked starts with "Back in April 2010, Russ Cox charitably suggested that only fannkuch-redux, fasta, k-nucleotide, mandlebrot, nbody, reverse-complement and spectral-norm were close to fair comparisons".
Since Russ Cox is one of the Go co-developers, lets see the ones he accepts are fair. Of those 5 are present in the page, on 3 of which Java wins with decent margins (fannkuch-redux: 18%, k-nucleotide: 21%, reverse-complement: 17.5%) and on 2 of which Go barely comes ahead (fasta: 6.3%, spectral-norm: 6%).
Highly debatable. Even then, you see that golang ranks in the 102nd place for the plaintext benchmark, almost 6x slower than Netty, which is very established in the JVM world. Same with the JSON benchmark, golang is in the 126th place, ~3.5x slower than Netty and Vertx.
> but Go usually use between 3 and 10x less memory.
The JVM by default will use whatever memory is assigned to it. This makes sense from an efficiency and utilization point of view, as it generally aims for maintaining good throughput (whereas golang is only tuned for latency). The JVM now ships with new low latency GCs (ZGC and Shenandoah) which are currently available in experimental phase.
That is for the purpose of "measuring the quality of the generated code when both compilers are presented with what amounts to the same program." But Go also allows pointers to fields and array elements and by design reduces pointer indirections and allocations in general, which those comparisons don't capture.
> Go was written for servers, Kotlin for mobile apps.
Not really. Kotlin was just a better JVM language developed by the JetBrains folks before Google adopted it as a first class Android language, but I don't believe it was specifically developed for mobile initially.
The open question is if Java will start borrowing the best features from Kotlin and it will become less relevant (like Scala). To Kotlin's credit, it has better IDE support, it feels simpler than Java (whereas Scala feels more complex), and it cleans up a lot of fundamental language issues that Java can't get away from.
Kotlin is just a less verbose, more modern language targeting the JVM. It has nothing to do with mobile apps beyond that Google, much later, decided to support it for Android development.
Go is an efficient platform, however in these switches it usually goes something like "we took something hugely overbuilt, with layers and layers and layers and abstractions and abstractions, and rebuilt it with minimalist Go and now it's faster", which, of course it is.
I don't think that's true. You're confusing the fact that Kotlin has become the officially supported language for Android development with the idea that it was written for mobile apps.
You may be confusing the adoption of Kotlin for Android. That happened more recently Kotlin has been open source since 2012 and designed as a direct (compatible) replacement for Java.
I wouldn’t say that Kotlin was written for mobile apps. JetBrains, the company that created Kotlin, doesn’t even have mobile apps AFAIK. It’s just meant to be a more modern JVM language and that means it does anything Java does just better. Servers included.