Go, Go, Go, Said the Old Programmer

The other day, a query crossed my desk about Google’s public release of its new Go programming language – a fascinating and probably often applicable new take on the genre. As sometimes happens in these cases, what remains of my memories of computer science resurfaced as I read Google’s description of Go. And so, what follows are some possibly useful thoughts about its features.

Before I start, let me sum up, for those who dislike tech jargon (and especially jargon from someone who has not wielded a debugger in anger for a couple of decades): Google Go is worth playing with, for a wide variety of programming needs. Check it out.

Error Handling Without Exceptions
I have been waiting for many years for some recognition that error handling is actually on a level with writing correct code. To put it another way, each recognition of the possibility of an error is like the old case statement, in which good programming considers the “error” cases as just as important to code as the “correct” case.

Google Go has two back-to-the-future ways of approaching this: first, rule out “exceptions”, and second, allow multiple return variables/values. I agree with their critique entirely: an exception was always treated exceptionally, making programming more complex, and the ease (and decrease in bugs) from having one return value was more than counterbalanced by the complexity of trying to report errors in odd ways.

I do have one caveat: I am not yet convinced that programmers don’t need some form of coercion to make sure that errors are adequately handled. I don’t care whether it’s a required error value in the multi-value return or what, I just feel that error handling is still not as good as it should be.

No Assertions?
I hear Google’s point that these have been misused in error handling. However, I would suggest that the proper place to handle this type of misuse might be in the compiler, if possible. Assertions should still be used to check assumptions between two key lines of code, because simply forcing proper error handling does not account for major blind spots in the programmer’s view of his/her own code or his/her knowledge of the language. In other words, there still needs to be a final fallback check.

High-Level Concurrency and Goroutines
Now here’s a refreshing approach to concurrency and parallelism! It passes belief that we have not been able to categorize types of concurrency well enough to take the mechanisms up a level and hide things like mutexes. Likewise, goroutines seem a small-overhead way of adding some additional “multithreading” parallelism – and I suspect that this will compensate partially for the need for scaling software multithreading now that multicore chips are muddying the waters.

At the same time, I note a lack of consideration of the equivalent problem in data sharing. Let’s face it, not all data is isolatable in objects, and so concurrency of unitary data-processing functions (e.g., add, delete, update, read) needs a database-type “commit” consideration of concurrency.

No Type Hierarchy, No Type Inheritance, Interfaces
I don’t think I have a real feel for what “interfaces” are, but the idea of jettisoning object-oriented programming’s type hierarchy is a fascinating experiment. The reusability and careful thought about relationships between object classes have always been to the good, but at scale (something that we have been butting up against since the mid-1990s), the sheer effort of keeping track of that hierarchy placed severe limits on the ability to reuse code, and slowed down programming. I hope this one works; if it does, it will give a major boost to programming speed for Java types.

Focusing on string and map support
I don’t have a good feel for this approach to maps, as yet, but thank heavens someone realized that strong string operators were a very good idea. Anyone who ever had the privilege of using SNOBOL soon realized just how useful these can be.

Garbage collection and compiled code
I regard this as a sign that finally compilation speed within a virtual machine has come of age. It was always true that compilation is preferable to interpretation if compilation is infrequent, as long as the recompilation “hiccup” is not significant. I hope that Google Go really can make this work; there is, imho, a fair amount of legacy Java code out there that’s really sub-optimal in performance.

And, by the way, embedding decent online garbage collection in the machine is a major step forward, as well. After witnessing the birth pangs of JVMs in the late 1990s, I am well aware of the perils of memory leaks and other related ailments. I really think that, this time, we can do garbage collection and object-oriented long-running programs without major overhead. If so, it’s going to be another improvement in software quality from Go.

Assumed Architecture
If I understand what Google are saying, there’s a complex interplay between clients and servers in the typical Go process that should provide some better scalability in the typical Web situation. I’m not entirely convinced that the architecture is flexible enough, but it seems to me pretty easy to improve on the present client/Web server/app server architecture. I’m all for trying it.

No pointer arithmetic
Oh, yes. Finally, after all these years, that mess left over from the original C design back in the 1970s can be eliminated. It was a cute idea when it arrived; but it was soon apparent that its problems from increased nasty bugs outweighed its small benefits in performance in certain cases. I hope this puts a stake through its heart.

Minor caveats
Google has noted that performance out-of-the-box is in some cases not in striking distance of C. They make a reasonable case that that will go away; but frankly, as long as it’s within shouting distance of C, Go should be preferable. It’s much better at preventing nasty little programmer errors, which means that programming speed will lead to faster improvements in performance which will more than make up for C’s “coding on the bare metal” virtues.

Meanwhile, I’m still not convinced that Go (like all the other object-oriented or semi-object-oriented languages) really does an adequate job of handling data. The emphasis on structure orthogonality is good, but from my viewpoint, minor. We are still back in the days of the object-relational mismatch.

Simplified typing? Simplified dependency management? Simplified multicore concurrency? I’m not convinced; but I’m definitely hoping it’s true in the general case, not just within Google. Anyway, it’s worth it just to see another experiment shake up the programming world.

Repeating the Message
The quote in the title, by the way, is from T.S. Eliot’s first Quartet, “Go, go, go, said the thrush …”. Like the thrush, an old programmer thinks you should go and play with Google’s Go. After lo these many years of dealing with Java and JavaScript development, at the least, it will be a mind-opening change of pace.