> Yet the majority of Google's problems are solved with Python, Java, Kotlin, and C++, not Go.
That's not very informative... Google had millions of lines of code in Python, Java, and C++ before Go hit 1.0 (to the extent that Kotlin enjoys wide adoption inside Google, it could be explained by compatibility with existing Java code, especially the Android niche). It would be more interesting to look at Greenfield projects which don't depend on existing Google libraries, although even then Go would have to be quite a lot better than the competition in order to get a team with a long history of proficiency in Java to migrate to a new, relatively unproven language.
> Go doesn't address any Python issue, besides AOT compilation, easily solved if PyPy had more community love.
Are you suggesting that if PyPy had more investment it would become an AOT compiler rather than a JIT compiler? Anyway, "if only the community invested in it more" is like the whole problem with the Python ecosystem. If the community invested in solving package management, Python wouldn't have such an abysmal package management story. If the community invested in a smaller C extension interface, PyPy could be fast and compatible and CPython would be freer to optimize without worrying about breaking compatibility.
I've been working with Python professionally for ~15 years now and I'm pulling for it, but come on... The idea that Go is only better with respect to AOT (ignoring that AOT is not an end to itself) is out of touch with reality. Go is 2-3 orders of magnitude more performant than Python, it's statically typed (yes, mypy exists but it's still alpha quality and I'm happy to back up that assertion if necessary), it has a sane package management story (yes there are warts, but that's still far better than the Python package management story), documentation is much better in every respect (the tooling, the centralization, the readability, the accuracy, etc), etc. These aren't small things--I've seen projects fail for poor performance, and I've spent weeks trying to find a way to get fast, reproducible builds (before giving up).
There are certainly areas where Python bests Go (e.g., data science ecosystem, web frameworks, etc), but the idea that Go only has AOT over Python is absurd.
Had Docker not happened, and the Kubernetes team not gotten some new members that pushed for the Go rewrite from the original Java prototype, most likely we wouldn't be even talking about Go.
No doubt those are prominent applications in the Go ecosystem, and thus I can understand why people with little Go experience (or little experience circa 2012-2015) have this perception, Go was gaining momentum in the devops and network-services spaces before those apps came to fruition.
Personally, I started using it because it was the only language at the time that made it easy to build and deploy static binaries--I didn't have to learn a DSL to download and wire together a bunch of dependencies (nor run a flaky daemon in the background because the performance of the CLI is so poor) or cargo cult the incantation to package them into an archive or figure out how to make sure that my targets have compatible versions of the target runtime or etc. Similarly I didn't have to figure out how to wire together a third party testing library and integrate it into the build system. Similarly I didn't need to worry about packaging and hosting my libraries or documentation. I also didn't need to operate an external web server like uwsgi or jetty--Go's standard library has a production-quality HTTP server builtin (and its concurrency features made it fast and scalable). The language features were also a pretty big boon: it had value types, first class functions, type inference, "duck typed" interfaces, goroutines, etc and best of all: an ecosystem free from the pitfalls of OOP (inheritance, banana-gorilla-jungle architecture, etc).
Frankly, it's just an amazing little language. I do wish I could take its runtime, tooling, familiar syntax, etc and plug in a different type system, mostly one with rust-like enums and generics; however, the particulars of a static type system are relatively minor factors in the outcome of a given project.
At the time Go was getting started most software was either Java which had to coordinate with the JVM installation or scripting languages which required you to manage a bunch of packages. Static binaries was virtually a feature unique to go from the point of view of popular languages in the domain of web dev and dev ops.
Three of the other languages are for Microsoft's Enterprise needs which significantly predate are distinct from Google's.
COBOL solves a problem Google doesn't have: producing code that a non-technical person can learn to read and understand. The general. The CEO.