Credentials: I started using Go around 9 years ago and since then I've built a company of over 1,000 employees with ~250 engineers that write Go full time. We maintain dozens of open source projects and libraries (Terraform, Vault, etc. etc.) all written in Go. We've shipped commercial products that are used by a significant percentage of the F500. Vault for example serves trillions of secrets per year for _one_ company that we know of.
I could probably write pages and pages so I'll try to highlight a few things. Go is not a perfect language or community by any means but I love it.
NOTE: Folks often read this feedback with the opinion of "but language X can also..." or some variant and I hope that doesn't come across. My feedback is not against any other language unless I'm specifically using an example. Another language might solve all these same problems for you! I'm just sharing how Go has been fantastic at these aspects for us.
== Junior and new-hire friendliness
Go is a very simple language. From the beginning of the company until now, we can hire people who have never used Go, point them at a couple resources (i.e. Tour of Go), and they can be committing to production-grade projects within a week. It is incredible.
Go makes it really hard to do anything that isn't obvious. The cost of this is often verbosity or repetition. But the benefit above is well worth it in my opinion. I know lots of people disagree with this but I personally prefer to repeat "if err != nil" 1,000 times versus introducing new control flow options that now must be educated.
I love telling new folks (junior or not): read the file top to bottom, that's how it'll execute. And for the most part, that's true.
As someone who built a rapidly growing team/company around Go, this has been indispensable.
Any "general purpose language" can theoretically write any software. However, I'm sure we'll all agree that its easier to write some software in certain languages, and that's a good thing.
However, I've been blown away by how flexible Go has been without feeling forced. We've written desktop CLIs, web APIs, distributed systems, security software, networking software, infrastructure software, accounting software, bots, etc. all in Go.
And most of these categories are at a scale of millions of downloads per year and successfully in production.
It's very cool to see that coming from a prior major background in Ruby where there were significant tradeoffs when doing these things. It was _possible_ of course but you had to really understand the tradeoffs you were making. In Go, there's certainly some tradeoffs but they've been minimal and Go has just worked.
As both an individual contributor and manager, this flexibility has been awesome in building a company around.
== Cross-platform Compilation and Statically-Linked Binaries
Since the first day I adopted Go 9 years ago, Go has encouraged and simplified static binary compilation and simple cross-platform compilation. Today you basically set an env var of what platform you want to target, run `go build`, and it usually works.
You still have to learn of various gotchas around platforms (API availability, filepath awkwardness, subprocess/signal behavior, etc.) but the compilation aspect alone makes it so much easier to tackle this task.
My previous experience of at-scale software I built was Vagrant in Ruby, and making that work across platforms was a constant, enormous challenge. I had to spend a few months full time just to get installers to help setup the proper runtime environment across platforms.
Looking at this also from the perspective of rising popularity with ARM systems and other less standard architectures (even Power for enterprises...), this property of Go has been very important.
The culture surrounding the Go community is generally one that is very philosophically aligned with how I view software. I would roughly describe it as pragmatic & measured.
I think this culture is exactly why many people dislike Go (or seem to "hate" it which I think is a pretty wild emotional reaction to a language for programming computers but I digress).
The Go community doesn't chase the next hot thing or rush to implement the "state-of-the-art" without a very measured, pragmatic approach. Some view this as Go being inferior by some definition but I view it as a huge benefit. Go core in particular appears to me (I'm not part of the core team so purely an opinion) to be a measure-twice-cut-once (or maybe measure like 8 times) approach. And I love that.
At the end of the day, the language is generally fun for me. I like writing it. And that's important, too.
I'm very lucky that Go took off as a language in the industry I built my company in. It certainly wasn't that way when we started using it (it was pre-1.0, pre-Docker, pre-K8S, the majority of infra sw was still in Ruby).
I feel that the language is super productive (we built Vault 0.1 in ~6 weeks for example), it has shown to scale to the largest needs and does so stably (Vault is in the hot path of every trade in one of the major US stock exchanges and has never gone down there), and we've been able to build a large company and active OSS community around it.
Hands down a successful choice for us with zero regrets.
Although I don't write Go so much anymore, I had the benefit of working in Go for a few years on a team that developed a strongly shared style. A few years later, one of those team members sent me a package they had been working on, and it was an absolute breeze to understand in comparison to the Rust and TypeScript I had been working on. This is not to knock on Rust or TypeScript, as there are absolutely solutions that are better expressed in those languages, but if I'm honest, the vast majority of software is "plumbing" - get data, manipulate data, put data - and Go is an extremely pragmatic choice for this in my opinion.
A few other thoughts...
I really don't take issue with `if err != nil` and though I like Monadic types, I'll take errors as values over exceptions 100% of the time.
I've also written a lot of CLIs and Go's build process here is superb.
I think the Go community has a strong testing culture, and although I like BDD, the work put into the std test tooling has really helped form that.
> The cost of this is often verbosity or repetition
This may be seen as a cost but it's also a significant gain during debugging.