Categories
Go Programming

Another Go at language design

The other day I attended a very interesting talk at the University of Melbourne given by Rob Pike.  The title was “Another Go at language design” and it was all about Google’s new programming language, Go.  It was a high level overview of the language with an emphasis on why certain design decisions were made.

Here is a random selection of the things that struck me as most interesting.

  • Pike lamented the state of modern industrial languages, by which he meant C++ and Java.  He started with a quote from Dick Gabriel “Old programs read like quiet conversations between a well-spoken research worker and a well-studied mechanical colleague, not as a debate with a compiler.”  In particular, one of the aims of Go is to show programmers whose only exposure to static typing is through C++ and Java that statically typed languages can have the simpler, more concise feel (fewer declarations!) of dynamically typed languages like JavaScript and Python.
  • Compile times of Go programs are small.  This is because the compiler doesn’t need to know about transitive dependencies between packages (their name for modules).  For example, if you have a file A.go which depends on B.go which depends on C.go, at first you have to compile C.go, then B.go, then A.go.  But all the information exported from A.go is stored in the compiled B.o file, which means that if you recompile A.go you don’t have to recompile anything else.  Hmm, now I’m unsure if that’s exactly right.  But the broader point is that the language avoids C++’s problem where bazillions of header files have to be read for every module.  He said with a completely straight face that their goal was to have a 1,000,000x speed-up over C++ for the compilation time of large programs, though they’d probably be satisfied with 100,000x.  Impressive!  Imagine if Firefox compiled in less than a second.
  • Identifiers that start with an upper-case letter are public, and identifiers that start with a lower-case letter are private.  The other language I’m familiar with that has a similar distinction is Haskell, where identifiers that start with an upper-case letter are used for types, and identifiers that start with a lower-case letter are used for values.  The nice thing about Go’s approach is that it gives you strictly more information:  you can determine from an identifier’s use point whether it’s public or private, which saves you from having to find it’s declaration.
  • There is no automatic conversion between numeric types.  This is for simplicity;  Pike said (probably exaggerating) that 1/3 of the C standard deals with this topic.  But the handling of numeric constants avoids many cases where explicit conversions are needed, because numeric constants are platonic in the sense that they don’t have a particular type until they are assigned to a variable.
  • They have a reformatting program, gofmt, that rewrites Go code into an “approved” layout.  This ensures that all Go code looks consistent, and avoids fights over style.  (Robert O’Callahan would approve!)  Interestingly, gofmt is separate from the compiler, and the idea is that you run it once you have finished a change.  At Google when code is committed into a repository, gofmt is run and if the layout doesn’t match the code is rejected.  I asked why they made it a separate program, rather than having stronger syntax/layout checking in of the compiler.  He said that (a) they hadn’t thought of putting it in the compiler, (b) it seemed like it would be less painful to just run it occasionally rather than having to worry about it every time you compile, and (c) it would slow down the compiler.

It was a good talk, Pike is an engaging speaker.  I’m glad he made the trip to Melbourne.

2 replies on “Another Go at language design”

also ruby cares about case of identifiers, uppercase identifiers are read-only/const.

and in ruby class members are reffered to with a @ prefix, also giving you right away information about their scope. static with @@, globals are prefixed with $.

btw if compiling is so fast it could make writing IDEs with smart completion, tags and so on much easier and IDEs could go higher-level and become more powerful than they are today.

Comments are closed.