What do the presentation (or our discussion) gain from the fact that Brad is a super smart guy "much more capable than the 'typical' programmer"? Why are we even bringing up that point? :)
As with all anecdotal language advocacy, you have to take it with a grain of salt, and in this case maybe more than usual.
Within Google today, if you're directly using local disk instead of the Google storage stack, you're going to have a bad time. Even more so if you're calling read() from a single-threaded event loop.
So, for me, that is somebody who didn't follow the state of Go libraries, it was much bigger new information in the presentation the author's certitude that some library covers everything of the standard (good to know how much care was invested there!) than the fact that when somebody has already made some very good tools he can more easily use them then probably anybody else who'd start without such a deep knowledge.
My own takeaway was "now that I know that at least some libraries are very well thought-out that's a good argument to consider when deciding about the use of Go in some future project." Still it's to weight against the learning curve and the quality and ease of use of the available libraries in other more common languages. In that light it's still good to know that the author of the presentation is really very competent.
Not directly related to your question, I also applaud the author's honesty in describing the problem he solved: first, the underlying assumptions changed: I can imagine that the main reason for fetching the data to the local disk in 2007 was that then fetching the data directly from the remote storage was much slower than it is now, making his current approach impossible then. Second, it's not that the original design was as inefficient as the later suboptimal modifications made it. Third, it was a project in which for a while nobody wanted to invest the time to. That's the convenient point to jump in and demonstrate what you can do with the new tools and your knowledge and time. Once you change the equation, a product once almost without the future can become a basis for future much more successful projects.
> The Go libraries are something very new. People who
> developed the libraries know them inside out. Outside of
> that group of people, there's certainly much less
> knowledge about them.
So it's a word of confidence that, yes not only is the interface nice, but the implementation is also good (enough) -- and you probably won't regret leaning on it in a future project.