It's worth reiterating that Go was created by Google to solve Google's problems. If it also solves your problems, or a worthwhile subset thereof, then that is a happy serendipity, but it's not a design goal.
In the words of Rob Pike:
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." – Rob Pike 1
The problem Go solves is that google has a bunch of people who can hack out code, but don't really know the theory of computer science, can't understand high level abstractions and complex type systems... So they need a language for "the average programmer", or as pg would say, "the blub programmer".
They invented the blub language. Blub programmers are everywhere at google, and they are everywhere in the industry, so its primary design goal is applicable to almost every company in the world.
The GC in Go punts the issue of memory management to the runtime, but does so in a largely correct way. In that one way, Go is easier than rust in a way which genuinely does not cause any real production issues.
However, the most important tradeoff when talking about Go vs Rust on this startup-infested hellsite is not related to the quality of code at all.
The goal of a startup is not to produce working production code, but rather to convince VCs of its trajectory. VCs don't care about buggy code. Every company has buggy code, it's expected you have bugs. Normal. Possibly even a good sign. "Move fast and break things". What matters more is the number of warm programmer butts you have in seats. VCs want you to hit your headcount targets, and unfortunately, hiring programmers that will make your codebase a buggy spaghetti mess is much easier than hiring Rust programmers.
Said another way, good code might actually be a problem in startup-land since it will make it harder to meet VCs hiring expectations.
That "key" is making Rust the complexity issue it is. Which is why it is considered so hard to pick up, both by newbies, and by experienced programmers. And yes, I know, there will be people who say "Rust is easy!". Well, show me people who learned most there is know of Rust over a weekend, or who understood a large Rust codebase while still learning the language. In Go, I personally know several people who did both. In Go I onboarded people who never before even saw any Go code, without an issue.
> Golang doesn't really solve the problems of newbies, it just punts the issues to runtime
These are not problems of newbies.
Yes, GCs are an adequate solution to the complex problem of memory management. Most real world production code written doesn't have performance constraints that prohibit the use of a GC.
Rather than being explicitly designed for problems Google was facing, it took a fair amount of time to find a niche (initially, log processing).
I believe that it is very much a problem many entities that aren't Google like to have a good solution for.
These things are quite subjective. In practice though, Go lacks the kinds of features that would make very large scale codebases (the sorts of codebases where "many coders ... work on the same thing") truly surveyable, understandable and easily maintained. I mean, it's not a complete disaster like Python or JavaScript. It has some features to support modularity and programming "in the large". But other modern languages like Rust or even Swift are quite a bit better on that side of things, and it shows.
In practice though, there is a reason why Go is seeing continuous growth in usage, so I kinda doubt that these features of Go are subjective.
> But other modern languages like Rust or even Swift are quite a bit better on that side of things, and it shows.
In what metrics does that "show" if I may ask? Because it isn't showing in usage numbers across projects.
Perhaps these features you speak of don't matter as much as we think.
Us mere mortals are trying to pick up Thor's hammer at the end of the day.