{"id":822,"date":"2009-11-11T16:08:33","date_gmt":"2009-11-11T16:08:33","guid":{"rendered":"http:\/\/scientopia.org\/blogs\/goodmath\/2009\/11\/11\/googles-new-language-go\/"},"modified":"2009-11-11T16:08:33","modified_gmt":"2009-11-11T16:08:33","slug":"googles-new-language-go","status":"publish","type":"post","link":"http:\/\/www.goodmath.org\/blog\/2009\/11\/11\/googles-new-language-go\/","title":{"rendered":"Google's New Language: Go"},"content":{"rendered":"

I’ve been being peppered with questions about Go<\/a>, the new programming language just released as open-source by Google. Yes, I know about it. And yes, I’ve used it. And yes, I’ve got some strong opinions about it.<\/p>\n

Go is an interesting language. I think that there are many fantastic things about it. I also think that there are some really dreadful things about it.<\/p>\n

A warning before I go on: this post is definitely a bit of a rush job. I wanted to get something out before my mailbox explodes :-). I’ll probably try to do a couple of more polished posts about Go later. But this should give you a first taste.<\/p>\n

<\/p>\n

The natural question is, what does it look like? It’s vaguely C-like, but with a lot of cleanups and simplifications. Every declaration is preceded by a keyword that identifies what it’s declaring: type<\/code>, func<\/code>, var<\/code>, or const<\/code>. Lots of parens that are required in C have been removed. The type declarations have been cleaned up quite a lot – they’ve gotten rid of the type-declaration garbage of C.<\/p>\n

In every declaration, the name comes first, followed by the type. So, for example, types are declared after<\/em> variable names, and all type modifiers precede the types. So *X<\/code> is a pointer to an X<\/code>; [3]X<\/code> is an array of three X<\/code>‘s. The types are therefore really easy to read just read out the names of the type modifiers: []<\/code> declares something called an array slice; “*” declares a pointer; [size]<\/code> declares an array. So []*[3]*int<\/code> is an array slice of pointers to arrays of three pointers to ints.<\/p>\n

Functions in Go are amazing. They start off really simply, but by providing a few simple extensions, they let you do all sorts of things. To start off, here’s a factorial function in Go.<\/p>\n

\nfunc Factorial(x int) int {\n  if x == 0 {\n    return 1\n  } else {\n    return x * Factorial(x - 1)\n  }\n}\n<\/pre>\n
 Go extends that by adding support for named return values. You can declare the return value as a variable in the function header; then you can assign values to that variable. When the function returns, the last value assigned to the return variable is the return value. So you could also write factorial as:<\/p>\n
\nfunc Factorial(x int) (result int) {\n  if x == 0 {\n    result = 1\n  } else {\n    result = x * Factorial(x - 1)\n  }\n  return\n}\n<\/pre>\n
 You can also write a function with multiple return values:<\/p>\n
\nfunc fib(n) (val int, pos int) {\n  if n == 0 {\n    val = 1\n    pos = 0\n  } else if n == 1 {\n    val = 1\n    pos = 1\n  } else {\n    v1, _ := fib(n-1)\n    v2,_ := fib(n-2)\n    val = v1 + v2\n    pos = n\n  }\n  return\n}\n<\/pre>\n
 It’s not object-oriented in a traditional way; it provides something like a limited form of object-orientation using another extension to functions. You can define new types – either type aliases, or structure types. You can declare methods for any<\/em> type at all in the module where it’s defined. A method is just a function which has a parameter preceeding<\/em> the function name.<\/p>\n
 So, for example, a basic linked list could be implemented as;<\/p>\n
\ntype IntList struct {\n  next *IntList\n  val int\n}\n\nfunc (s *IntList) SetNext(n *IntList) {\n  s.next = n\n}\n\nfunc (s *IntList) GetNext() *IntList {\n  return s.next\n}\n\nfunc (s *IntList) SetValue(v int) {\n  s.val = v\n}\n\nfunc (s *IntList) GetValue() int {\n  return s.val\n}\n<\/pre>\n
 One of the dominant themes that you’ll see as I continue to describe it is minimalism. The guys who designed Go were very focused on keeping things as small and simple as possible. When you look at it in contrast to a language like C++, it’s absolutely striking. Go is very small, and very simple. There’s no cruft. No redundancy. Everything has been pared down. But for the most part, they give you what you need. If you want a C-like language with some basic object-oriented features and garbage collection, Go is about as simple as you could realistically hope to get.<\/p>\n
 To give you one example of that minimalist approach, Go allows you to define types with methods. But there’s no such thing as a class, and there’s absolutely no inheritance. Instead, there’s a kind of composition. I won’t go into detail about it here. <\/p>\n
 As I said above, you can define methods on any<\/em> type. The methods are really just functions with a special parameter. There’s no such thing as a type constructor! There’s an allocation operator, “new” – but it doesn’t initialize values. You can’t provide Go with any automatic initializer. Instead, things like constructors are handled by convention. You’ll generally create a new data type inside of a module. That module will have a public function named “New”, which returns an initialized value. So, for example, there’s a module named “vector” containing an implementation of a vector; to create a vector, you import the vector module, and call vector.New(size)<\/code>.<\/p>\n
 Another example of that minimalism is the way that they handle abstraction and name hiding. There are exactly two kinds of name visibility: public, and private. Private things can only be seen in the module that declared them; public things can be seen in any module that imports them. The way that you make things public is by lexical cues: public things are things that weredeclared with an identifier starting with an upper case letter. “fact” is private, “Fact” is public. <\/p>\n
 The most innovative thing about it is its type system. There are two kinds of types in Go: concrete types, and interface types. Concrete types are exactly what you’re used to from most programming languages. Interface types are similar to interface types in languages like Java, with one huge<\/em> exception: you don’t need to declare what interface types you implement! An interface is a specification of what methods a type must provide to be used in some context. Anything<\/em> which implements those methods implements the interface. Even if the interface was defined later than a type, in a different module, compiled separately, if the object implements the methods named in the interface, then it implements the interface.<\/p>\n
 To make that even better, methods aren’t limited to objects. In fact, Go doesn’t really have objects. Any value, any type at all, can have methods. So you can make an integer type with its own methods. For example:<\/p>\n
\ntype Foo int;\nfunc (self Foo) Emit() {\n  fmt.Printf(\"%v\", self)\n}\ntype Emitter interface {\n  Emit()\n}\n<\/pre>\n
 Foo<\/code> implements Emitter<\/code>. I’ve created the type “Foo”. Values of type “Foo” are integers. Then I’ve implemented a method on an instance of “Foo”.<\/p>\n
 That’s brilliant<\/em>. I absolutely love it. And even in the relatively small amount of time I’ve spent hacking Go code, I’ve seen it pay off, when I’ve created new interfaces, and realized that old types already implement the interface. It’s a very elegant idea, and it works really well. It ends up giving you something with the flavor of Python-ish duck typing, but with full type-checking from the compiler.<\/p>\n
 For example, the first thing I wrote in Go was a parser combinator library. I defined an interface for the input to a parser:<\/p>\n
\n\/\/ ParserInput represents an input source readable by a\n\/\/ parser.\ntype ParserInput interface {\n  \/\/ Get the character at an arbitrary position in the\n  \/\/ input source.\n  CharAt(i int) uint8\n\/\/ Get the number of characters in the input source.\n  Size() int\n}\n<\/pre>\n
 Now, anything that implements CharAt(int)<\/code> and Size()<\/code> can be used as an input to a parser. Then, I defined an interface for parsers:<\/p>\n
\n\/\/ ParseValue represents the type of values returned by\n\/\/ successful parses.\ntype ParseValue interface { }\n\/\/ A Parser is an object which parses input sources. The\n\/\/ framework of parser combinators provides a very general,\n\/\/ backtracking parser.\ntype Parser interface {\n\/\/ Run the parser on an input source, starting with\n\/\/ the character at a specified position. If the parse\n\/\/ succeeds, it returns \"true\" as the status, the\n\/\/ number of characters matched by the parser as the match_len,\n\/\/ and an arbitrary parser-specified, return value as the result.\n\/\/ If the parse fails, then it returns false as the status, -1 as\n\/\/ match_len, and nil as the result.\n  Parse(in ParserInput, pos int)\n    (status bool, match_len int, result ParseValue)\n}\n<\/pre>\n
 So a parser is anything which has a Parse<\/code> method. A parse
\nmethod takes an input, and a position in the input; and it returns three
\nvalues: a success code (indicating whether the parse succeeded or failed); a match length (indicating how many characters in the input were accepted by the parser), and a return value. The return value can be anything<\/em>: it’s defined as an empty interface, and everything<\/em> implements the empty interface.<\/p>\n
 To build parsers, you start with a kind of parser that can process a single input character, which is any character from some set of characters.<\/p>\n
\n\/\/ CharSetParser parses a single character from among a\n\/\/ specified set.\ntype CharSetParser struct {\n  chars string\n}\nfunc (self *CharSetParser) Parse(in ParserInput, pos int)\n    (status bool, match_len int, result ParseValue) {\n  status = false\n  match_len = -1\n  for c := range self.chars {\n    if self.chars[c] == in.CharAt(pos) {\n      result = self.chars[c]\n      match_len = 1\n      status = true\n    }\n  }\n  return\n}\n<\/pre>\n
 This demonstrates one sort of odd feature of Go. A structure and a pointer to a structure are different types<\/em>, and they can have different methods<\/em>. A pointer to<\/em> a CharSetParser<\/code> is a parser; but a CharSetParser<\/code> is not!<\/p>\n
 The implementation above doesn’t provide a way of creating a CharSetParser<\/code>. To do that, we need a function. And to try to make the parsers look as clean as possible, we’ll name it so that it doesn’t look like a creator function, but just a parser itself:<\/p>\n
\n\/\/ Create a CharSetParser which accepts any one character\n\/\/ from a specified string.\nfunc CharSet(s string) *CharSetParser {\n  return &CharSetParser{ s }\n}\n<\/pre>\n
 Then you add more kinds of parsers which allow you to combine simple parsers. For example, one combinator is repetition, which runs a parser over and over until it succeeds:<\/p>\n
\n\/\/ ManyParser is a parser that parses a repeated syntax\n\/\/ element. It succeeds if the sub-parser succeeds at least\n\/\/ a specified minimum number of times. Returns a list\n\/\/ of the results of the sub-parses.\ntype ManyParser struct {\n  min int\n  parser Parser\n}\n\n\/\/ Create a ManyParser which matches min or more\n\/\/ repetitions of the sequence parsed by p.\nfunc Many(p Parser, min int) *ManyParser {\n  result := &ManyParser{ min, p }\n  return result\n}\n\nfunc (self *ManyParser) Parse(in ParserInput, pos int)\n    (status bool, match_len int, results ParseValue) {\n  status = false\n  curPos := pos\n  numMatches := 0\n  stepResults := vector.New(0)\n  stepSuccess, stepLen, stepResult := self.parser.Parse(in, curPos)\n  for stepSuccess {\n    numMatches++\n    curPos = curPos + stepLen\n    stepResults.Push(stepResult)\n    stepSuccess, stepLen, stepResult = self.parser.Parse(in, curPos)\n  }\n  if numMatches < self.min {\n    stepSuccess = false\n    match_len = -1\n    results = nil\n    return\n  }\n  status = true\n  results = stepResults\n  match_len = curPos - pos\n  return\n}\n<\/pre>\n
 With that, you just say Many(P, 0)<\/code> to represent a parser that parses 0 or more repetitions of P. <\/p>\n
 Anyway, the end result is a library where you can write lots of very simple functions which combine parsers in very flexible ways. The end result is something where I can write a parser that parses lisp SExpressions into a cons-list structure with: <\/p>\n
\nSexprParserRef := MakeRef()\nManySexprs := Action(Many(SexprParserRef, 1), new(VectAction))\nListParser := Second(Seq([]Parser { Lp, ManySexprs, Rp }))\nSexpr := Alt([]Parser{ ListParser, SymParser })\nSexprParserRef.SetTarget(Sexpr)\n<\/pre>\n
 Alas, not everything about it is so wonderful. Sometimes that minimalism comes back to bite you on your ass. And worse, there’s a bit of a “for me but not for thee” attitude that pervades some aspects of the language design.<\/p>\n
 For one example of an odd minimalist tradeoff: they decided that they didn’t want to specifically add something like an enumeration type. After all, what’s an enumeration? It’s really a type-safe alias for an integer, with a set of constants defining the members of the enumeration. Go already has the ability to define a type-safe alias for an integer! So why bother allowing the definition of a new kind of type? Instead, just make it easy to define the constants. So they created a pseudo-variable named iota<\/code> which can be used inside of a constant declaration block. Each time you see a semicolon in a constant block, iota is automatically incremented. So to define a set of colors, you could do something like:<\/p>\n
\ntype Color int\nconst (\n  RED Color = iota\n  ORANGE Color = iota\n  YELLOW  Color = iota\n  GREEN Color = iota\n  BLUE Color = iota\n  INDIGO Color = iota\n  VIOLET Color = iota\n)\n<\/pre>\n
 That will create a color type,  with “RED” as 0, “ORANGE” as 1, etc. Of course, it’s kind of annoying to have to re-type the iota every time. So if you omit the values after an iota in a const block, it automatically just copies them. So you could rewrite the colors as:<\/p>\n
\ntype Color int\nconst (\n  RED Color = iota\n  ORANGE\n  YELLOW\n  GREEN\n  BLUE\n  INDIGO\n  VIOLET\n)\n<\/pre>\n
 It seems a bit strange and obtuse, but not awful. But it can get downright strange. Here’s an example from the Go tutorial:<\/p>\n
\ntype ByteSize float64\nconst (\n  _ = iota;\t\/\/ ignore first value by assigning to blank identifier\n  KB ByteSize = 1<<(10*iota)\n  MB\n  GB\n  TB\n  PB\n  YB\n)\n<\/pre>\n
 Iota starts at 0. By assigning it to “_”, you effectively discard the zero value. Then, “KB” is defined as 210*iota<\/sup>. That full expression is then copied to the successive values. So MB gets a copy of Bytesize = 1<<(10*iota)<\/code>, which evaluates to 1<<(10*2). And so on. Since ByteSize<\/code> is an alias for a float64<\/code>, the values are automatically converted to floats.<\/p>\n
 It’s powerful, but if you ask me, it’s ad-hoc and ugly.<\/p>\n
 Then there’s the “We’re the language designers, we need stuff you don’t”.<\/p>\n
 The Go type system does not<\/em> support generic types. They’re considering adding them at some point in the future, but for now, they don’t consider them necessary. Lowly programmers just don’t need<\/em> parametrics, and it would clutter up the beautiful compiler to implement them.<\/p>\n
 Oh, but wait… Go really<\/em> needs type-safe arrays. Well, that’s OK. Everyone provides arrays as a sort of special case – what language doesn’t have typed arrays, even if it doesn’t have any other parametric types? And we really want these cool things called slices – but they really need to be strongly typed. So we’ll let them<\/em> be parametric. And maps – we really need a map type, which maps keys to values, and it really needs to be type-safe. So we’ll add a parametric map type to the language, by making it a special case built-in.<\/p>\n
 So: you can’t write parametric types – but they<\/em> can. And that creates a very weird asymmetry to the language. Everything in Go is passed by value – except<\/em> for the built-in slice and map types, which are passed by reference. Everything is allocated by “new” – except<\/em> for the built-in slice and map types, which are allocated by “make”. It’s by far the biggest blemish in Go, and it’s absolutely infuriating.<\/p>\n
  •  There’s a similar issue around error handling. The language doesn’t have exceptions. I can accept that – exception handling in most languages is absolutely hideous, and you can make a strong argument that it’s so damned broken that you should find a way to do without. Particularly in a language like Go, where you can return multiple values from functions, you can do things like return both a result and a status code, and handle errors via status codes.<\/p>\n
     So the Go guys left out exceptions. They say that you don’t need them. But for their own code, they added workarounds that become something like exception handling for their own code. For example, if you want to do a cast from an interface type X to an interface type Y, you’d write something interface type to another, you’d write “y = x.(Y)<\/code>“. But if the value x didn’t implement interface Y<\/code>, it would be an error, and the program would crash. So if you’re not sure that x implements Y<\/code>, you can write “y, ok := x.(Y)<\/code>“. That never fails; if x implements Y<\/code>, then y gets the casted value, and ok is true. If x doesn’t implement Y<\/code>, then y get assigned nil, and ok is set to false. Once again, having a way of catching an error is OK for the language designers, but not for anyone else.<\/p>\n
     Anyway, with the complaints out of the way: one other major piece of goodness is compilation speed. One of the fundamental goals of Go was to be able to compile things really<\/em> quickly. Lots of things about the language were designed to make it possible to build a really fast compiler, and to be able to do full separate compilation without every needing to re-process anything. (The motivation for this is that at Google, we have a very large code-base with tons and tons of code re-use. This is a very good thing. But because most of that code is C++, builds can be incredibly slow. The way that C++ header files work with a standard compiler, you can wind up re-parsing the same file hundreds or thousands of times. So even with a really fast compiler, you can easily wind up with some extremely slow compile times. Tricks like pre-compiling headers can help, but they’ve got their own problems.)<\/p>\n
     Go programs compile really astonishingly quickly. When I first tried it, I thought that I had made a mistake building the compiler. It was just too damned fast. I’d never seen anything quite like it. I’d taken a parser combinator library that I’d written in Java, and re-implemented it in Go – the full version of the code that I excerpted above. The code was slightly more than 30% shorter in Go, and also cleaner and prettier than the Java. A full, clean build of the combinator library in Java took just over 3 seconds in Eclipse. It took 0.6 seconds on the command-line compiled with Jikes. With the 6g go compiler, it took 0.06 seconds!<\/p>\n
     Before using Go, Jikes was the fastest compiler I’d ever used. But Go managed to do better by a factor of 10! And Jikes was generating Java bytecode; 6g is generating reasonably well-optimized native code! Part of that is the genius of Ken Thompson, the guy who implemented 6g; but part of it is also the very careful design of the language.<\/p>\n
     (Boneheaded mistake 2: for some reason, I always confuse Ken Thompson and Dennis Ritchie. It’s Ken who wrote 6g, not Dennis, as I originally wrote.)<\/em><\/p>\n
     So… At the end of the day, what do I think? I like Go, but I don’t love it. If it had generics, it would definitely be my favorite of the C\/C++\/C#\/Java family. It’s got a very elegant simplicity to it which I really like. The interface type system is wonderful. The overall structure of programs and modules is excellent. But it’s got some ugliness. Some of the ugliness is fixable, and some of it isn’t. On balance, I think it’s a really good language, but it could have been a lot better. It’s not going to wipe C++ off the face of the earth. But I think it will establish itself as a solid alternative. And hopefully, over time, they’ll fix some of the worst parts of the ugliness, without sacrificing the beauty or simplicity of the language. (Addendum 2011: I’ve used Go a whole lot since I wrote this… and at this point, I absolutely love<\/em> Go. It’s become one of my favorite languages. It’s just so much fun<\/em> to program in. Yeah, it’s got its blemishes – but it’s a delight to work with.)<\/p>\n
     To preemptively answer a question I’m sure people will ask: am I using Go for my daily work? Not yet. My project has a lot of existing code, and at the moment, I’m constrained by that. I’ll be starting work on a prototype of a major new component very soon, and once I’ve had time to look at the foreign function interface for Go, I’ll make a decision about whether or not to use it. Basically, if the FFI is good enough to allow me to link to the Google infrastructure that I need to be able to use, then I will use Go for my prototype, and hopefully for the full component.<\/p>\n","protected":false},"excerpt":{"rendered":"
    I’ve been being peppered with questions about Go, the new programming language just released as open-source by Google. Yes, I know about it. And yes, I’ve used it. And yes, I’ve got some strong opinions about it. Go is an interesting language. I think that there are many fantastic things about it. I also think […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[54],"tags":[],"class_list":["post-822","post","type-post","status-publish","format-standard","hentry","category-programming"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p4lzZS-dg","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/822","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/comments?post=822"}],"version-history":[{"count":0,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/822\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/media?parent=822"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/categories?post=822"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/tags?post=822"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}