[SquishyPanda23]

> To be readable, usable.

Go doesn't particularly value readability or usability. For example, the short variable name convention makes it harder to read code you're unfamiliar with, and there are a number of noticeable usability shortcomings, some of which are mentioned in the article.

I think Go's design goals were really to (1) reduce compilation time, which explains why Go has human programmers do work that compilers do in other languages, (2) be statically typed and compiled, so you can use it conveniently for microservices, and (3) have syntax somewhat similar to Python.

I think of Go as the successor to Java. Go is to Python as Java was to C++. That, plus the integration with many libraries is why it's taken off in some niches.

[throwaway894345]

Honestly the biggest selling point of Go to me was that it's simple and consistent. It enforces strong opinions that I may disagree with, but it means everyone does things generally the same way which is an important component in readability. With respect to short variable names, the convention is to only use them for very local scopes (e.g., using `i` as a loop index variable). In particular, I don't need to learn a new language or run a daemon just to compile code with a few dependencies and ship a static binary. Similarly, I don't need to configure CI pipelines just to publish packages or documentation. I don't need an IDE, I don't need to shop around for a test framework or an external web server process because they're built in. I don't have to think about what version of the runtime and/or dependencies are installed on my target system. Plus performance is good and the ecosystem is substantial. Personally from experience, I weight these kinds of concerns a lot higher than whatever bells and whistles are available inside of the language.