What relevance does that add to this presentation? It's interesting by itself.
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? :)
A bunch of "typical" programmers wrote a program in C++, and it turned out crappy. A "super smart guy" rewrote it in Go, and it turned out nice. How much of the delta between crappy and nice was due to the language, and how much to the programmer? (And how much is due to the new programmer learning from the old programmer's mistakes?)
As with all anecdotal language advocacy, you have to take it with a grain of salt, and in this case maybe more than usual.
Brad even acknowledges that the original program was nice in it's day. C++ complicated things but it sounded like the bigger problem was developers leaving the team and new features being hackishly implemented.
And don't underestimate "changing environment". As Brad said, "in 2007, using local disk wasn't restricted ... in 2012, containers get tiny % of local disk spindle time ... cluster file systems own disk time on your machine, not you."
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.
It gives the fuller perspective. 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. A lot of the claims in the article about the full coverage of some standard in some Go library versus the incomplete one by the given C++ program obviously come from somebody who invested enough time to study the standards and (at least) study the implementation inside of the said libraries. That is, something like that either you know or you can just say authors claim that they adhere to the standards -- which ones, how much; you can't know, much less you are able to compare.
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.
I guess it's a tautology that the people who developed something know it best, but you're being really disingenuous here by implying that only those people would be capable of doing a project like this. Go's stdlib HTTP server takes great pains to be accessible and powerful.
I think the implication was that the developers know the actual capabilities, and so know if there were any dark corners of the standards that were just papered over with stuff that might break in some subtle way, in non obvious use-cases.
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.
It adds some validity to the opinions and points he makes? I will certainly pay more attention to a presentation if I know that the presenter has credibility..
Comments
What relevance does that add to this presentation? It's interesting by itself.
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? :)
A bunch of "typical" programmers wrote a program in C++, and it turned out crappy. A "super smart guy" rewrote it in Go, and it turned out nice. How much of the delta between crappy and nice was due to the language, and how much to the programmer? (And how much is due to the new programmer learning from the old programmer's mistakes?)
As with all anecdotal language advocacy, you have to take it with a grain of salt, and in this case maybe more than usual.
Brad even acknowledges that the original program was nice in it's day. C++ complicated things but it sounded like the bigger problem was developers leaving the team and new features being hackishly implemented.
And don't underestimate "changing environment". As Brad said, "in 2007, using local disk wasn't restricted ... in 2012, containers get tiny % of local disk spindle time ... cluster file systems own disk time on your machine, not you."
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.
It gives the fuller perspective. 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. A lot of the claims in the article about the full coverage of some standard in some Go library versus the incomplete one by the given C++ program obviously come from somebody who invested enough time to study the standards and (at least) study the implementation inside of the said libraries. That is, something like that either you know or you can just say authors claim that they adhere to the standards -- which ones, how much; you can't know, much less you are able to compare.
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.
I think the implication was that the developers know the actual capabilities, and so know if there were any dark corners of the standards that were just papered over with stuff that might break in some subtle way, in non obvious use-cases.
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.
It adds some validity to the opinions and points he makes? I will certainly pay more attention to a presentation if I know that the presenter has credibility..