A Commentary On Three Quotes From “Working on the Go Team at Google”

(https://medium.com/@ljrudberg/working-on-the-go-team-at-google-917b2c8d35ff)

“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’.

I already have a fair idea of why they might do such a thing, an idea confirmed by the nature of Dart itself. Dart is designed with similar syntax to JavaScript, a language and ecosystem that even more than Go attempts to avoid such difficulties, but with the object model and type system from Smalltalk, a language most often used when things must work. Might it be the case that JavaScript doesn’t work when development requires solving difficulties rather than avoiding them? And that Go doesn’t do anything significant to address that?

The first is not really guesswork, given that Google states as much on the Dart website — that JavaScript is unsuited for complex, scalable software. The second is more than implied by the fact that Go was released before Dart was even begun. Even Google is not in the business of throwing money away (although their purchase of Motorola might make some people question that claim).

Realistically Dart is unlikely to be successful, firstly because the difficulty associated with Smalltalk and similarly capable, reliable languages such as LISP and Haskell, as demonstrated by the lack of difficulty most developers have with Ruby, whose syntax is very similar to Smalltalk, is not primarily a syntax issue but an issue with thinking through writing programs in those languages, itself a result of restrictions designed to ensure reliable programming practices, and encoded in the case of Smalltalk primarily in the object model and type system; secondly because the size of user base with web browsers that can only run JavaScript is immense, and ‘Dartium’ must provide sufficient reason for Chrome users to bother switching, never mind users of other browsers, many of whom use them by corporate edict. Essentially, it must support relevant applications that are sufficiently useful to make switching attractive, and are sufficiently independent of the user base to not need to support that user base directly. That kind of “killer application” doesn’t come along often in any sense, and if it can be done with the platform users already have, it generally will be.