I encounter a lot of different software stacks when helping clients as a consultant. Consultancy is something I do next to my main job which is being a CTO of a small, bootstrapped startup. That sounds like a posh job but what it really means is that I do most of the technical work together with one other person.

I've always been opinionated about tools and languages. And we probably all have our biases and preferences. What I've realized doing consultancy is that it's rarely advisable for me to tell my clients to change whatever the hell they are doing. It's actively harmful to do so. And I encounter pretty much everything you can name. Including Go.

At the same time, it's taught me to steer clear of certain tech stacks for my own things. I know I don't like them by virtue of having seen others do things with them. Go, is one of those things that's arguably alright and widely used. But I wouldn't prefer it based on what I've seen.

The reasons are mostly non technical:

1) it's a transition language for people. They might start with something like Javascript or python and they might crave something a bit more rigorous. Go is an easy choice. It's there, it's widely used. It has great libraries, and so on. But I've seen people progress to other languages as well. It's a phase people go through as they develop themselves. And there's a definite "if you have hammer, every problem looks like a nail" thing going on with it. For me Go would be a step backwards, not forwards. I have some languages I'm interested in learning. Go is not one of them.

2) it's a Google language and Google has this big "not invented here" syndrome that often translates into them reinventing wheels. In this case C++. They embarked on their journey around the same time several other languages kicked off. Rust, Swift, Kotlin, etc. all emerged roughly around the same time (15-20 years ago). Swift is Apple's language and it suffers from the same issue. So, even though Google's take on this is interesting. It's not the only one or necessarily the best one (subjective of course). Rust and Kotlin are a bit less tied to one company. And both are widely used across most/all big tech companies and less entrenched in just one of them. Full disclosure, I prefer Kotlin out of these languages and actually use it for a lot of things people might think Go is good at.

3) It's a conservative language community. Despite being relatively new, the community seems to resist change a lot. Endless debates about exception handling, package management, generics, etc. and other aspects of the language seem to progress at a snails pace with people bickering endlessly about whether that's good or bad design. That stuff just bores me. Just fix it already. I don't want to read/hear endless reasons why something cannot/must not/should not be a thing because reasons that boil down "we don't like change".

So, no Go for me. But some of my clients use it and it's of course fine for them. I consult them on what they should build, not how to build it. A lot of that stuff works just about the same regardless of the language. Use what works for you, what you are familiar with, etc. Not what others tell you to use.