> -- Operational complexity vs. Go.
The JVM is superior for operations, observability, and monitoring to anything that golang has to offer.
>> Disagree on operations part. Take a bare machine and with various configurations (some you don't control) and be ready to drop and run. Nothing beats Go. You cannot be simpler than copy a binary. Yes, the JVM has all sorts of observability. And also a load of tuning that often needs to occur. Go just runs and generally has outstanding performance.
> -- Deeply-nested code directories.
I've seen the same in golang code due to its packaging.
>> Go code is generally not as deeply nested. Often you have <project>/<package>/<file.go>. Not stuff like:
tomcat/java/org/apache/tomcat/websocket/server/xxxx.java
> -- 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.*
>> Friend, I'm talking about all the packages here:
https://golang.org/pkg/
> -- 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.
>> Yes, mu point (Xmx, GC settings, future things). Many dials == complexity.
> -- Concurrency model, as compared to Go.
Java is getting green threads (see project Loom), and they'll be superior to what golang offers.
>> More Java getting/future vs. Go has today. "they'll be superior to what golang offers." Since we are predicting the future, can I also get next week's S&P500 level for my trades?
>> Let me know when you can remotely close to writing <200 LOC that can handle 1m websocket connections from a laptop. There are 2 source files here.
https://github.com/eranyanay/1m-go-websockets/tree/master/4_...
Again as I opened with, these are my experiences. If Java and the future versions of Java and the tolling, IDEs, CI/CD tools, inspectors, etc, work for you. Great. Have at it.
I will keep deploying rock solid Go applications with minimal complexity and maximal performance/reliability, out of the box. I shall enjoy flatter code trees, working without a IDE when necessary (totally possible), enjoying simple make files for builds, and solving a ton real world problems with minimal external libraries (again, dependencies ~= complexity ~= risk).
Checkout some great stats from the 2019 Go Survey here: https://blog.golang.org/survey2019-results
I will depart with a final thought about Go: Why are increasingly more and more web-scale infrastructure projects being written in Go? (CockroachDB, Openshift, NATS, Docker, Istio, Etcd, Docker, K8S, large parts of AWS, Azure, and CGP).
