A Google Development Team Comes Together
Meanwhile, another Google engineer, Ian Taylor, saw the draft specification for the language and told the trio he had written a GCC front end for it. So he joined the team. Russ Cox joined about a year ago. And in the last couple of months another Google engineer named Adam Langley joined the team and has been helping out with a lot of library work and getting an SSL (Secure Sockets Layer) implementation in native Go, Pike said. Jini Kim is the product manager for Go and organized many aspects of the launch. 6. How Go speeds up development"So one of the things we did with Go is we are very rigid about dependency specification. And the language actually yells if you try to pull in a dependency you don't actually use. This guarantees a minimal tree and that really helps the build. And there's one more very technical thing that is really important and that's the idea that we pull the dependency information up the tree as we go so that you only look at anything once. You never compile anything more than once when you're doing a build. And that's a huge improvement in performance relative to the normal C family of languages." On this point, Pike also said, "The languages people use for building large software systems nowadays are typically languages like C++ and Java, which were designed pretty much a generation ago in terms of programming abilities and understanding. And they're not aging very well. And we realize that there are things like the advent of multicore processing and the dominance of cluster computing and things like that really needed a rethink at the language level. So we tried to bring in some of our background in distributed systems and concurrent programming and stuff like that." 7. Google Go has an unusual type system Pike said some have described Go as object-oriented programming without objects. Instead of having a notion of a class and then defining all the methods for that class and then subclassing and so on, Go is much more orthogonal, he said. "You write down the types as storage buckets that implement things," Pike said. "And then you can have what we call interfaces, which are pure abstractions about behaviors of those things. And when you want to write a program that needs something like a 'write' or a 'sort' you just say I need something that knows how to write or that knows how to sort. You don't have to explicitly define a subclass of something from a sorting interface and build it down. It's all sort of much more compiler-derived instead of programmer-specified. And a smaller point, but it matters to some of us is that you can put a method, in the object-oriented sense, in any type in the system."
"One of the big problems with development that sounds very uninteresting and unsexy [is] maintaining the dependencies-what you need to build first in order to build this thing you're trying to build now, such as the libraries, the packages, layers of software," Pike said. "And languages like C++ and C in particular make it very hard to guarantee that you're not building anything that you don't need to. And we've investigated this in some detail and found that it's a huge reason, almost the dominant reason why build times are so slow for large C++ applications.