I've never once had a problem with Go's documentation and it started out as a relatively casual project that is more peripheral to Google's interests than Servo is to Mozilla's.
Making a language be able to get picked up by the wider programming community means somebody has to spend time on things other than the compiler. Lots of time.
That said, the compiler needs a lot of work as well, as those who have used the language for any amount of time can attest to. Everyone sees the dreaded "internal compiler error" message. Everyone encounters borrow check and code generation bugs. Everyone misses a working package management system and pretty printer. Everyone bemoans the slowness of compilation for small programs. These are things you just didn't see for Go when it was announced--because it was Google-internal then.
We intend to fix the documentation before calling it 1.0. But compilers are complex, especially for a language with a rich type system and a nontrivial static analysis built in (the borrow check). There are many things to do, from documentation to bug fixing to feature work (macros and default methods are unfinished) to tooling work.
Note, however, that the code examples in the documentation are kept up to date and enforced via the test suite. So there may be inaccuracies in the prose, but we do perform automated quality control as best we can.