You don't need to configure the JVM as in many cases the defaults are fine. And most of the frameworks in use today do not require an application server.
Go is definitely simple. But I wouldnt characterise modern day Java development as being that complicated.
Well, you don't need the JVM and any dependencies it pulls. That's also worth something in the era of "cloud" services. Less to install. Less to update. Ideally you only need to update the deployed application. Which in case of Go is that one binary.
Another big thing is that same app written in Go just takes (significantly) less RAM than when written in Java. Go has arrays (and slices) of structs, not just struct pointers (in Java-speak: object references). This also dramatically reduces short lived garbage. Additionally Golang strings consume less memory, as they are UTF-8 by default in memory. In Java, you can start JVM with -XX:+UseCompressedStrings option, but that adds branches and still falls back to UTF-16 when string contains non-ascii characters.
Yes, computing resources, including computing power, memory usage and storage are limiting factors and they do increase cost. One instance - who cares. 1000 instances and you might care. Something you ship for other people to run? End users might care.
Give me ssh, and I can deploy my app to default installation setup in a second, like CentOS 6. That includes binary transfer, installation and startup.
Hot deploy is nice. Sadly Golang is one of the only language environments where you just can't do it. Do watch out, the issues you'll encounter may be rather unique. Especially when applied in production...
Java also has arrays. And on heap/off heap RAM allocation.
We deploy all our services as uberjars, we have a single Amazon AMI with JDK 8 installed. It's pretty frictionless. It goes from a simple Gradle project, to a single jar on S3, and pulled from S3 by our AMI. Automatically launches via an upstart script.
I'll give you less RAM usage for sure. But when I'm launching a whole VM for a service anyways, I don't care that much. I tend to lean toward Go when I want a low-footprint coprocess for another service, or other small apps.
Comparing Java's off heap allocation to golangs (or the CLRs) structs is pretty misleading isn't it? I mean there are all kinds of things you can do off heap to reduce gc, but the other platforms make it easy.
Java doesn't have Object or any Object derivative arrays. Only elementary types can be arrays. Of which reference type is one. So when you say:
Integer[] boxedInts = new Integer[5];
You're allocating an array of references with length of 5, so usually 5 * 4 + 8 bytes. Additionally, each of the referenced Integer Object instance take up 16 bytes. Multiple arrays (or reference fields) can refer to same Object instance.
The example was about Integers, but it's basically the same story for FactoryWorkerPersons.
Java doesn't have arrays of objects. Only arrays of elementary types, up to 2^31-1 entries.
I see you use both Groovy (for Gradle) and Golang. Do you have any installation problems with version management using "GVM", the name chosen for the popular "Go Version Manager" and then used again for VMWare's "Groovy Version Manager"? The Groovy project managers haven't made clear whether they're going to fix this problem, or even explained why they used a name already in use. That project seems to have lots of issues over choice of names.
Go is definitely simple. But I wouldnt characterise modern day Java development as being that complicated.