[TheDong]

Go solves an industry wide unchanging problem.

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.

[zozbot234]

I agree that this is a real problem, but newer languages like Swift and Rust are targeting newbie coders while keeping the benefits of advanced type systems. The key is to surface errors in compiler diagnostics, so that the newbie coders know when they're getting it wrong. It's using the compiler as a friendly TA. Golang doesn't really solve the problems of newbies, it just punts the issues to runtime where they will likely end up causing breakage in production.

[TheDong]

> Golang doesn't really solve the problems of newbies, it just punts the issues to runtime where they will likely end up causing breakage in production.

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.

[usrbinbash]

> The key is to surface errors in compiler diagnostics, so that the newbie coders know when they're getting it wrong.

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.