[DLA]

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

[pjmlp]

Because of cargo cult of "must be web scale" and people that want to pump up their CVs to work at a FAANG.

All those projects are related to Docker and k8s, so naturally get written in Go.

Thankfully it is also possible to use Rust, C++, Java and .NET with them without writing a single line of Go.

[DLA]

You could write any program in any non-toy language, of course. This does not make every language a good choice for a given problem.

Here’s some pretty detailed notes from Google about one high volume project they rewrote from C++ to Go.

https://talks.golang.org/2013/oscon-dl.slide#1

Use whatever language you like. Just because you like X and someone else likes Y does not invalidate either language.

And to you totally off base comment about cargo cult of web scale and ‘pump up their CVs’ .... in my case I happen to work with huge data (petabytes) so yeah it matters and has nothing to do with FAANG. In this context I have found Go to be an insanely great tool—-productive, reliable, maintainable, multi-core, networked and fast. Thankfully I will never have to write a line on .NET.

[pjmlp]

Ah the rewrite that was driven by the Go team itself as a means to prove a point.

Apparently the Android team did not adopt gomobile the same way.

[DLA]

Yes and they are very clear about that. What matters is the end result. Shorter, simpler, higher perf code that solved a practical problem, at scale. There's no secret that Brad is a heavy for the Go team. The point is about one way to pragmatically solve a problem and ship code. That's all.

[pjmlp]

Yet every time a new SDK comes out of mountain view it still is mostly about C++, Java and Python as tier 1 support, and only occasionally with either Go or Dart support.

Also apparently having Go on Fuschia is not well seen and it will eventually be replaced by a C++17 or Rust implementation.