Recently, Google presented its new programming language, Go, and declared it open-source.
Go is meant to be a small and simple systems programming language, safer than C, and allowing for short development times. Go programs compile very fast, themselves being ‘typically 10-20% slower than C’. The authors also say that Go is very productive to write in.
Of course, the great interest that is being generated around Go has to do, for now at least, not so much with the language itself as with who is behind it. It is not ‘just’ the giant Google corporation; Go is designed and helped being implemented by a bunch of persons of immense prestige in programmerhood.
Listed as principle designers are Robert Griesemer, Rob(bert) Pike and Ken(neth) Thompson. Thompson is the one who created the very initial Unix, co-created Plan 9, and wrote numerous programs for them that are used worldwide. Pike was also a member of the great Unix team (although, being somewhat younger, he came to it later), was deeply involved in the creation of Plan 9, Inferno and the Limbo programming language, and is widely known as a co-author of books with Brian Kernighan. Of Griesemer I knew nothing, but a short Internet search revealed that he was a student of Niklaus Wirth – the prominent computing pioneer and creator of Algol W (with C.A.R. Hoare), Pascal, Modula, and the Oberon language and operating system.
Ian Taylor, of GCC's autotools fame, and Russ Cox, well known in the Plan 9/Inferno community, are said to have helped, in a way or another, in implementing Go.
* * *
So I was, very naturally, curious about what the new language is like. I read some of Go's definition, the FAQs, other documents, even watched the video, trying to extract not only what the language authors are willing to tell us but also what they omit, deliberately or not. Here is a summary of my findings, mainly centred around the facets of Go that make it different from C, and grouped in decreasing order of my liking them. I am just listing these, with almost no commenting.
I wrote all of this down because I thought other programmers might by interested in comparing Go to C without having to read too much of the official documentation. This includes myself, in a couple of weeks from now.
structs + procedures (methods) attachable to types. This is a simple, flexible, effective and efficient construct of object-oriented flavour. The mechanism of type extending is also a type-safe replacement for unions.structs (so, one can define, say, a synonym of int, and thus furnish ‘ints’ with new methods).init() functions: dependent package-level variable initialization per source file.defer statements).structs, arrays, slices, and maps.for loop of two forms, one similar to C's, and one for iterating through an array, slice, string, map, or the stream of values received on a channel.for is the only kind of looping construct in Go.ifs can have prologues.const pi = 3.141592653589793238462643, which is beyond what can be represented in a float64.These may be good or not. I have no definite opinion on the value of any of them.
const declarations.:= as an initializing operator in variable declarations (different from =, assignment).iota in place of named integer constants and enums. iota is a compile-time generator of sequential natural numbers, starting from 0 in every new context.fallthrough statements for switch cases. (Unlike C, falling through is not default.); is a separator, not terminator, and is not needed at global level.ifs can have empty conditions, as in if {do something}.&^, ‘bit clear’: like & with a (bitwise) negated argument._ (underscore), to be used wherever the syntax requires a name but the corresponding value is not actually needed.union is usually embedded in a struct, which is a drudgery to the programmer and clutters up the program itself. The need for unions is being catered for through the mechanism of type extending. However, unions can be implemented safely, as Algol 68, CLU, and Ada exemplify, and using unions is simpler than imitating them.if has to be a block, but the else part can be a simple statement.make() for creating a slice which also creates the underlying array, dynamically. Thus, arrays are static, slices are dynamic.)i++ is allowed, and ++i is not. Pike says ‘the postfix version is more traditional’. I say it is bad taste. It breaks with the established tradition in writing mathematics: a monadic operator precedes its operand. It is also inconsistent with the other monadic operators in the language which are prefix.++ and --, are statements, not expressions., (comma) operator. (The need for it has been to a great extent obviated by multiple assignment, but still.)?:) in Go.do-while.Frankly, the ++/-- issue alone is enough to make me avoid this language if possible. Sheer ugliness!
And here is why I am finding Go's declaration syntax unattractive. They took from Pascal/Modula/Oberon the rule to write down variable names before types, but did not adopt the colon, and added the Algol 68 style of backward array type definition (e.g. []int). The resulting mix is uglier than any of the mentioned languages, and perhaps worse than C. Had they borrowed from only one of these languages (or from D, for that matter), the result would have been much better.
In Pascal or any of its descendants we write i: integer, whereas in Go it is i int. The latter is simpler, when taken in isolation, but consider a procedure header such as proc(a int, b, c float). With the colons retained, it would have been proc(a:int, b, c:float). Even better it is in the C/D style – proc(int a, float b,c) – and perhaps still better is proc(int a; float b,c). Any of these variants is better readable than the one implemented in Go.
I personally conceive of type names as similar to monadic operators, and therefore int i is preferable to me than i int. But more importantly, the syntax of a language should make program parts easily discernable. Go's variable declaration doesn't.
There are several issues of political nature with Go.
The Go authors say, in the FAQ, that ‘no major systems language has emerged in over a decade’. ‘Arguably longer’, adds Pike in his live presentation. Well, there is certainly at least one such language, D. By all measures it can be considered ‘major’, unless someone proclaimed a new meaning of the word. It is hard to believe that the sages are so uninformed as not to have heard of D. There must be another reason why they ignore D's existence. (Hint: there is a significant overlap between the publicly stated goals of Go and those of D, and D is widely considered a good design.) My guess would be that Google is after catching the attention of the open source community, as that community can greatly contribute to Google's success in whatever the company is seeking. In the game of winning hearts and minds D might be a rival.
The very name of the language is an issue. It clashes with the name of Go!: another language with similar goals (but much more different from C), introduced in 2003. Go!'s author requires that Google change the name of their language. I am unaware of how widely Go! is being used, but there is a published book on it. And again, it is hardly the case that nobody in Google knew about Go!. If they knew, why did they act as if they didn't?
And finally, the language Oberon and N. Wirth should have been acknowledged by Go's authors much more explicitly than with the single phrase ‘… significant input from the Pascal/Modula/Oberon family’ in the FAQ. As already mentioned, from Oberon Go borrowed the concept of extensible structs, as well as its attachable procedures. In view of Oberon having already, and for quite some time now, proven successful as systems programming language, the features now copied to Go are of great advantage to the latter. How come their inventor is not even mentioned?
Go may turn to be a useful and successful language. Or not. These things are impossible to predict.
Do I like Go? I do like some of its features, and I remain curious of how much I would like the exeperience if I program in it something not completely trivial.
But I know I am not going to love Go. True beauty evades this language. Go may be practical, but is also eclectic, and has taken some unconvincing or downright ugly design choices. It definitely lacks that subtle but unmistakable touch of elegance that makes a language great.