A Commentary On Three Quotes From “Working on the Go Team at Google”
“First, a little bit about myself: I am 23 years old, less than two years out of my undergrad degree at UW-Madison.”
This, really, needs little commentary … not because there’s anything wrong with being inexperienced, but because working on core technologies like programming languages and associated tools is precisely what experience is most useful for.
Without knowing the key difficulties in development not addressed by current technologies in a reliable and reasonably productive way, writing new ones is unlikely to improve anything relevant, and that knowledge usually only comes from having experienced those difficulties and the reasons current solutions are either unreliable or unproductive.
“In my time on the Go team, I met and spoke with the majority of the “Gophers”. The team works on the language itself, as well as various parts of the Go ecosystem such as libraries and Google Cloud integrations.”
In software development and numerous other fields, “Gofer” has for a long time been used to refer to someone not yet capable of doing real work, and therefore relegated to ‘Going-fer’ things people doing real work need. That the entire team, not merely one particular 23-year-old, are referred to as “Gophers” is interesting, at the very least.
“I met and worked with great people and hacked on interesting problems.”
Given that Go has been pointed out by numerous people as a great example of a waste of time, a language that doesn’t solve any relevant problems better or even as well as existing languages, and that introduces no features not already found in multiple existing languages, this rather handily accounts for that.
I have no difficulty believing the account precisely because having looked at Go, from the perspective of a somewhat polyglot developer with 26 years industry experience in 11 different language, not to mention hundreds of tools and frameworks based on those, Go fails to solve such inherent difficulties as lock free distributed programming while maintaining state, or further, doing so in a transactional manner, but instead tries to avoid them such difficulties, which in practical terms means increasing the complexity of other aspects of a given system, usually written, of course, in more capable languages, by more experienced developers.
Were Go as successful as this rather naïve developer appears to believe, I would have to wonder why Google felt it necessary to start YAFL project, namely Dart, afterwards, and perhaps more cogently why Google decided to hire several individuals who have more than 30 years language development each on one specific language to work on it. That’s not an inexpensive proposition no matter what language a developer worked on, but particularly not when one of the most cited reasons more companies don’t use that language, despite very high productivity metrics, is that any developers who simply know that language ‘cost too much’.