golang compile times are similar for any non-trivial project. Ironically, they're even much worse than Java's for quick changes (e.g. change a single file then recompile to run tests) since golang has to spit out a binary that is in the 10s of MBs compared to Java which just needs to change a single class file.
> -- Operational complexity vs. Go.
The JVM is superior for operations, observability, and monitoring to anything that golang has to offer.
> -- Verbose XML configuration files. > -- Lots of libs favor XML vice JSON. > -- Factories of factories of factories. :)
Nothing to do with the language.
> -- Deeply-nested code directories.
I've seen the same in golang code due to its packaging.
> -- Verbosity and boilerplate.
golang is more verbose and error prone for any non-trivial code base
> -- JVM install and config (many dials = control but also complexity).
The JVM is configurable and gives the user the ability to tune his program (say latency vs throughput), unlike golang which doesn't. Secondly, you can compile to native code using GraalVM.
> -- Concurrency model, as compared to Go.
Java is getting green threads (see project Loom), and they'll be superior to what golang offers.
> -- Impractical / painful to write without an IDE.
Irrelevant for any non-trivial code base, since golang needs and IDE as well.
> -- Std lib not matched to work I use Go for.
let's see what golang has to offer anything remotely similar to java.util.concurrent.*
> -- Memory consumption.
Depends on how you set up your JVM (Xmx, GC settings, etc.). Java is getting value types soon to address this even more.
> -- Performance (for the work I do).
They're on par, and for any non-trivial code base, Java tends to be faster.
> -- Multiple inheritance (allows unnecessary complexity).
Java doesn't support multiple inheritance.
