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.
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.