do not pass go
I've been looking at Google's new systems programming language Go. I think there'll be a lot more to say about it on this blog, over time. Which is to say that I expect it to become an important language, because C and C++ occupy a massive space in the industry and have some real flaws. Plus Rob Pike and Ken Thompson have an impressive track record. Add the attention only Google can get these days and I think Go has to be considered a player.
So first, thumbs up to Google for allowing one of their own, Mark Chu-Carroll, to do a lengthy blog post that was by no means all positive about his experiences using the language. Can you imagine Sun allowing that with Java on its much-hyped emergence in 1995, or Microsoft in its long tit-for-tat with C#? But to win the respect of real-world engineers this is the only way to go - to coin a phrase - and immediately led to a highly informative discussion.
Still, there's been a lot of moaning, especially from some older software types, typified by Jeff Bone. He makes valid points about how slow progress seems to be for the ordinary programmer in language, library and operating system design. But in the end my hunch is that getting concurrency right was never going to be easy, it was always going to be a multi-decadal job. I'm not even saying that Go has got it right. And it's notable of course that it's harking back to Tony Hoare and CSP from the 1960s. (Nice to see from Wikipedia that the great man is still alive to witness this, if he still cares!) But making channels first class objects and strongly encouraging data sharing through communicating processes (something that neither Chu-Carroll nor Bone really touch on) is for me a bet worth making, in a world of increasing multicore. I hope they're right, because we need all the help we can get with concurrent programming.
Alan Kay once said that a quantitative difference can make a qualititative difference - for example in the responsiveness of a user interface. It may be thought a low blow quoting Kay in support of Go - though I in turn appreciated the positive mention of Smalltalk by Pike in his introductory video - but I 100% endorse the emphasis on compilation speed and the automatic dependency detection that it partly relies on. These areas have been crying out for a clean up, as you know if you have done anything significant with C or C++ - and one has the impression that Google just might!
I'm also happy not to have to declare any interfaces for a type. Polymorphic dispatch comes out nicely from multiple implementations of the same interface - as an ancient object guy I'm happy with all that.
But in the end my sympathies are with Alan Kay when he said positively of C that it turned out to be the universal computer-oriented language many had hoped for (from the early 1950s) but "I don't think any human being should write in it." How different will Go be? I'm by no means convinced by the type system, by the 'special cases' of map, slice and channel, by a whole raft of things. Quoting Kay again (or at least someone's memory of the man): "We don't have a science of software engineering. Until we do, we should take advantage of late binding." You do get some late binding in Go, through the interfaces, but we don't yet seem to have created a compile-time-checked type system that is as fully productive for the ordinary programmer, especially in handling collections of objects, as the best run-time-checked systems, nowadays typified by Ruby in mainstream web development.
But passing over all that (as if he were heading for the jail in Monopoly for bad behaviour), it's as well to remember that Go presents itself as a "systems programming language". As such it seems a good effort. I hope it succeeds and becomes a favoured target, as a better-behaved and better-understood concurrent substrate, for faster and much more engaging end-user and exploratory programming environments than we've had to put up with in times past.