Bazel is not a Go default either. You can get very far just by using the default Go Modules, and this is much more common than repos using Bazel.
Throw some Makefiles and shell scripts in the mix, if that's your thing, and that's perfectly fine.
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.