Note added January, 2022: This document was written for Go's release in 2009, and has not been updated significantly since. Although it is a good guide to understand how to use the language itself, thanks to the stability of the language, it says little about the libraries and nothing about significant changes to the Go ecosystem since it was written, such as the build system, testing, modules, and polymorphism. There are no plans to update it, as so much has happened and a large and growing set of documents, blogs, and books do a fine job of describing modern Go usage. Effective Go continues to be useful, but the reader should understand it is far from a complete guide.
The very same "K" has co-authored the equivalent Go book: https://www.gopl.io/
I can only recommend it, though I wished they would make a second edition including all the new language features. But for the base language, it is still great.
I suspect the biggest annoyance for people new to Go using the gopl book will be the changes to the ecosystem (modules, go get changes, etc.)
You can learn a language without learning about $new_feature_x perfectly fine; this is something you can just pick up later. But if you run in to trouble with the first chapter because the commands no longer work then that kind of sucks.
What I would like is an official guide on how to set up go environment on various platforms. The language is stable, but tooling went through so many radical changes that most of the guides out there are outdated. And setting it up as you go just results in a messy setup.
Getting your editor up and running is still a mixed bag. "Install VS Code + plugin" sort of works, but you're likely to have a ton of bugs with the plugin that need configuration tweaks to work around (e.g., "try the LSP backend"). Hopefully stuff will stabilize as workspaces and generics stabilize.
I'm just starting out with Go, but how has the official guide[1] failed you? Genuinely curious as it seems to cover both new installations and the management of multiple versions.
There are a lot of different approaches listed in here that have changed over time. Different projects evolve at different rates. You might need to become familiar with multiple old ways of dependency management to be really effective.
Assuming that information is correct - and i'm not in a place to judge that, i just don't have the knowledge unfortunately - that journey felt pretty short and discoverable.
Are there really that many mainstream projects that use alternative dependency handling? Go modules were introduced in v1.11 and they seem pretty mature.
The replace directive seems to solve the issues with forked projects in particular. [1]
At the time when I was learning go (about 5-6 years ago), this document was a truly effective guide which would have probably wasted my time by a factor of 100 had it been a published book on the subject with hundreds of pages of fluff (just because that's what publishers like).