> -- Operational complexity vs. Go. The JVM is superior for operations, observability, and monitoring to anything that golang has to offer. >> Disagree on ope

> -- 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/ 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_optimize_gobwas 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 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).