Go is not a hyped language, we're past that cycle, some critical and widely used software are built in Go, millions of people rely on it.
I wouldn't call its tooling "a mess" but these days it's nothing notable either.
Python is at such a different point in the design space I don't think you can really compare the two. Same with PHP, Ruby, Javascript etc.
For OCaml, need to decide how strongly you want to commit yourself to functional programming. Also, didn't OCaml have weak support for concurrency? Has that changed recently?
Similarly with Rust, comes down how much you want to commit yourself to learning and conforming to the borrow checker.
Elixir is an interesting comparison, as it's another language that allows you to build highly concurrent back end services. The tradeoffs are that Elixir provides even more robust scaling due to the Erlang VM. But Go allows you to more easily understand and optimize the memory and CPU performance of your application.
Well, it’s quite easy to be fast if you are just spewing out barely optimized machine code. Compilers aren’t slow just for the sake of it.
And some things that slow down compiles are not to improve optimization. But to support complex, higher level language features. Go seems to hit a sweet spot of being highly expressive without slow compile times.
But even aside from that we were just talking about tooling at the moment.
OCaml has had Lwt for concurrent IO for long enough that it is now being deprecated in favor of Eio[1]:
You should have a look what the go command can do.
While not Go-specific, it's the extremely popular option in the space and I've seen it bring many-a-seasoned wizard to their knees in tears.
Also managing your go dependencies if you cargo-cult other Google behaviors like monorepos tends to be painful.
Basically just cargo-culting Google behavior == pain. Choosing golang can often be part of this behavior pattern.
Throw some Makefiles and shell scripts in the mix, if that's your thing, and that's perfectly fine.
Especially in a corporate space. It should be obvious that I'm referring to things that you see in a professional environment with professional standards. I'm getting a lot of hate where that seems to be lost on people.
And even if someone is a solo developer I don't assume that they don't ever have to work with other people's code -- that certainly wasn't my experience when solo contracting.
Nothing about Go's design should be talked about divorced from the context of it being tailor-built to solve Google-specific problems.
All other uses of Golang are basically in the territory of rounding error.
It was designed for Google, but Google has not adopted it widely. Google is still heavily C++ and Java after all these years. The outside world loves it way more. Kubernetes isn't used internally at Google (except Cloud, which is not any different from any other cloud provider) though it's sponsored by Google. Bazel is probably in a similar boat.
Being designed to solve Google problems doesn't mean that it actually solves Google problems well, or that Google thinks it does.
I became introduced to Go through my startup and my experience was it a delight to work with in very small teams.