I assume this refers to the overhead of the JVM itself. How high that is and how much that matters has been subject to debate, but I think it is objectively higher overhead cost than the Go runtime.

Without using containers or fragile (and not very portable) executable wrappers you need to manage the JRE, JAR files and the right classpath.

With go you can just run 'go build' and get static executables for all common platforms with zero dependencies.

The key difference between that and just throwing jar files on random systems is that static executables truly work anywhere and will never crash because you don't have the right version of JDK and usually won't need messing up with arcane command line parameters or .properties files.

Deployment is one area where Go truly shines and I guess that helped its popularity. PHP also got immensely popular due to ease of deployment, although of a different kind, in a different era and with different expectations.

To simply deploy a jar you need to have jar compatible JDK installed on that system. The effort towards that IMO is non-trivial.

Until Java 9, not a lot was done about the memory footprint of Java. Especially Strings, which were all stored in UTF-16 internally. For a language prone to Stringly Typed coding, that makes containers a hard sell, but caused issues just running it on VMs long before containers were a thing. Really this is something that should have been started for Java 7 and completed in 8.

They also kind of hit a wall around 1-2GB of memory that took ages to get past with GC. It had the potential to kill your 95th percentile numbers to have long GC pauses. It contributed to things like Redis and Memcached taking off because of how frequently you needed data close to you but couldn’t just keep it in process.

Most likely some old myth regarding the JVM.

Its actually trivial to deploy and updates are just pushing one file; your uberjar. This is so much better than anything node/ruby/python/php have to offer.

I also feel much safer running code in a VM on the server than directly native where a single invalid dereference brings down the whole thing in a rain of fire.

I suppose that "high-deployment costs" also includes JVM/application startup and warmup.

Likely they mean high RAM consumption?