I agree that it's very unlikely for someone to Go in a week and start writing flawless code.

But Go's real strength is in its readability, not writability. I think it's very much possible to learn Go in a week, then read clean Go code like the standard library and understand exactly what's going on. At least that's my interpretation of what it means for a new grad to be productive in Go in less than a week. Nobody is expecting someone new to write production-grade libraries with intricate concurrency bits in their first week, but they're already productive if they can read and understand it.

As a rule of thumb we spend 10x more time reading code than we do writing it (code reviews, debugging, refactors). So why not optimise for it?

As a fairly experienced engineer, I have to say that reading go code is what gives me the most pause. I find the amount of visual noise and lack of useful abstractions makes it so that to be efficient at reading code, I have to trust that the loop or the error handling code is doing what I expect. The issue with go is that the primitive operations are written `for i := 0; i < 10; i++` instead of `map` and `x, err := foo(); if err != nil {...}; bar(x)` instead of `y := bar(foo()?)`, which requires either presuming, or spending the mental energy ensuring the primitive was written correctly every time it is used.

I generally do the second, because doing the first is extremely tiring when reviewing code, but I dislike it immensely.