[thrownaway2424]

>>> For general use cases, the JVM has years of tuning behind it.

Much like that Camaro in my cousin's front lawn. The JVM has years of tuning behind it because nobody can make it work. It is so awful that there exist genetic algorithms[1] just to try to set all the GC parameters to something with good throughput and minimal pausing. Meanwhile, the number of times I've been paged in the middle of the night because my Go server's new-gen permanent eden survivor ratio was critically low has been exactly zero.

https://github.com/sladeware/groningen

[copsarebastards]

The number of times I've been paged in the middle of the night because my Java server had any issue caused by the JVM's configuration has been exactly zero, too. Basic configurations for both the JVM and Go are adequate for 99.99% of projects. You haven't run into problems in Go for the same reason that you wouldn't run into problems on the JVM--you're not writing 0.01% use cases.

According to Oracle, 3 billion devices run Java. That means that a JVM problem which occurs on 1 in 10,000 devices occurs on 300,000 devices. An obscure problem in the JVM can affect more devices than you'll probably ever write code for.

The other 0.01% of projects probably just don't exist yet for Go. If people start using Go on the same frequency, variety, and scale as they use the JVM, I'm quite certain that problems will arise which will require tools like groningen to solve. It's ridiculous to compare JVM tuning complexity with Go tuning complexity when Go hasn't been applied to a fraction of the problems that the JVM has.

[microtonal]

Basic configurations for both the JVM and Go are adequate for 99.99% of projects.

No! The standard Java maximum heap size is often not adequate for projects, and you have to find a sane value rather than letting your operating system do memory management.

[copsarebastards]

I said "basic configurations", not "default configurations".

I will say that I have run into this issue twice. In both cases, the solution was to eliminate fix code that were flooding the heap with unnecessary allocations.

There are certainly cases where you would want to increase the heap size, but those really are 0.01% use cases. More often than not, you should fix the code that's using so much memory. If your criticism of the JVM is that you wrote shitty code and your shitty fix for your shitty code was to configure the JVM, I'm not feeling a lot of sympathy for you. If that's the case, go be happy with Go, by all means. And if your use case really was one of the cases where increasing the heap size makes sense: well, that kind of project is going to cause issues for Go, too. Just because it silently allows you to pile your heap into the stratosphere doesn't mean it's going to deal well with your larger heap size. In fact, given that it's parallel mark-and-sweep (and not generational) you're almost guaranteed to have performance issues in larger heaps--it's geared toward low overhead and performance on smaller heaps.

As an aside: Azul systems produces a really cool JVM implementation called Zing that does some amazing stuff with pauseless GC. Worth checking out for anyone interested in GC implementation.