Java programs rely on the JVM, of which there are many variants. Run time options are often split into multiple XML files -- one file for logging, another to control the number of threads and so on. Checking for the running process using `ps | grep` yields some long line that wraps the terminal window, or doesn't fit neatly into columns shown in `htop` or `btop`.
These complaints are mostly about conventions and idioms, not the languages themselves. I appreciate that the Java ecosystem is extremely powerful and flexible. It is possible to compile Java programs into standalone binaries, though I rarely see these in practice. Containers can mitigate the messiness, and that helps, up until the point when you need to debug some weird runtime issue.
I wouldn't argue that people should stop programming in Java, as there are places where it really is the best choice. For example deep legacy codebases, or where you need the power of the JVM for dynamic runtime performance optimizations.
There are a lot of places where Go is the best choice (eg. simple network services, CLI utilities), and in those cases, please, please deploy simple Go programs. Most of the time, developers will reach for whatever language they're most comfortable with.
What I like most about Go is how convenient it is, by default. This makes a big difference.
And you left out classloader/classpath/JAR dependency hell, which was horrid circa late 90s/early 2000s...and I'm guessing was still a struggle when Go really started development. Especially at Google's scale.
Don't get me wrong, Java has come a long way and is a fine language and the JVM is fantastic. But the java of 2025 is not the same as mid-to-late 2000s.
But Go wasn't designed for CLI apps. It was designed for writing highly multi-threaded servers at Google, according to the designers, hence the focus on features like goroutines. And in that context startup time just doesn't matter. Startup time of servers at Google was (in that era) dominated by cluster scheduling, connecting to backends, loading reference data and so on. Nothing that a change in programming language would have fixed.
Google didn't use classloader based frameworks so that also wasn't relevant.
For example initial JIT caching experiments on OpenJDK came from J/Rockit.
I'm also not fond of any of the Golang syntax, especially not having exceptions. Or if you want explicit errors, fine, at least provide nice unwrap syntax like Rust does.
I had to, to make sense of whatever was going on.
If this is systems programming, yeah you're reasoning about channels, but that's mostly the same in any language. Golang has slightly nicer support for that if anything.
And with the increasing performance of Bun, it seems that Go is about to get a whooping by JS.
(Which isn't really true, as most of the Bun perf comes from Zig, but they are targeting JS Devs.)
None of these runtimes make JS anywhere even close to single-threaded Go perf, let alone multithreaded (goroutine) perf.
npm was also maybe the first default package manager that "just works," unlike Python or browser JS.