Go was announced publicly by Google in November 2009, and is intended to meet the challenges faced by modern software development. Specifically Go is designed to be fast (including at compilation time), support multiple cores and combine the ease of a dynamic language with the safety of a statically typed one. Mark Summerfield has recently released, "Programming in Go", a book intended to assist existing programmers in learning the Go language. InfoQ recently had the opportunity to discuss both the language and book with Mark.
InfoQ: What did you find that you liked about Go?
Mark Summerfield: There are lots of things I like about Go but I think the most compelling are:
- Lightning-fast compilation. This makes the edit/compile/run cycle almost as fast as Python's edit/run cycle.
- Really nice high-level concurrency. You can easily write concurrent programs in Go that have no explicit locks. Also the way goroutines are multiplexed over OS threads means that if your algorithm is best expressed in terms of 1000s or 10000s of concurrent processes you can create that many goroutines---whereas with threads it is usually best not to create too many of them.
- Zero initialization and garbage collection. Both these eliminate whole classes of errors and simplify coding.
- The language itself is small enough for the average programmer to master. Compare with C++98/03 which I think is already beyond the average programmer when you consider the templating language: and C++11 is even bigger and far more complex.
- The novel approach to object-orientation. I just find this approach interesting.
- The Unicode support. I really like the way Go lets you work with raw UTF-8 bytes or with Unicode characters depending on what you want to do.
InfoQ: What did you not like about Go?
Mark: At first I didn't like the error handling idiom (return an error value as the only or last return value) because I'm so used to using exception handling. However, I'm now perfectly happy with it.
One thing that I do miss is operator overloading. IMO the big package (for big.Int and big.Rat types) is really ugly to use because you can't overload operators. Also, although Go's "lack" of generics is only really an issue for library writers esp. since Go has far less need of generics because of other language features, having operator overloading for < would be really nice for defining custom data types.
InfoQ: From your author profile, I see that you have written several books about Python. How do you feel the two languages compare? What things about Go made you miss Python? Conversely, what things about Go made you forget about Python?
Mark: I would say that overall Python 3 is my favourite language. However, Go is my favourite compiled language.
I know that quite a few Python programmers have tried Go, but personally, if it is more performance they want I think they'd be better off using things like numpy and for fast algorithms using Cython.
Go was intended to be the C of the 21st century and certainly I think that Go will prove to be a very influential language. I'm sure it will result in other languages at the least adding CSP libraries to support Go-style concurrency.In terms of the language and standard library Go knocks the socks of C. However, C has a *lot* of third party libraries (although these can be used in Go by using the cgo package).
I think Go has enough high-level features to tempt Java programmers who want more performance, a nicer concurrency model, and a more liberal license.
I also think that Go has a lot to offer C++ programmers as an alternative to C++11. Go's standard library is much smaller than C++'s---but actually contains far more practical real-world functionality. Sure, C++ programmers will find Go doesn't have things they're used to---but compiling in seconds or minutes rather than tens of minutes or hours is very productive, and Go is much more maintainable than C++, particularly C++11, because it is a much smaller and more understandable language. And, of course, Go is just _one_ language not three like C++ (C pre-processor which has no knowledge of scope; C++ runtime language; C++ compile time language---templates).Also, Go programs compile down to a single executable with no external dependencies. This makes deployment, e.g., across all the machines in an organization, much less painful than having to be concerned about whether all the machines have the same libraries etc.
The Go language is both familiar (in the C family) and yet takes some quite radical stands on key issues (object-orientation, concurrency, error handling, lightweight syntax) that make Go worth learning, at the least to see a viable alternative approach for mainstream programming.
InfoQ: I really appreciate the comparisons you made of Go to other languages - especially outlining how it has reduced complexity compared to C++11. Do you see the changes of C++11 as being significant enough to cause existing programmers to consider a switch to Go if they have the freedom to do so?
Mark: Although I think that going from C++98/03 to C++11 represents an _opportunity_ to re-evaluate and to switch to Go, I don't think that most will actually do this. C++ requires a very big investment in learning: I suspect that many programmers would rather go forward with a subset of C++11 than change languages, esp. to a language that is smaller than C++ (and therefore seems to have less features). Naturally _some_ will make the change to Go, particularly those who have applications that would really benefit from Go's high-level concurrency model.
With C++98/03 we already have the situation where many programmers use a particular subset of the language that they're comfortable with. This can cause problems when two or more C++ programmers who use different subsets must work together or maintain C++ code they didn't write. I think that C++11 will considerably magnify this problem.
Java was designed to be a simpler better C++ and succeeded in many ways. Go is designed to be a better C, so my expectation is that it will win more C programmers (for whom it is all gains) than C++ programmers (for whom it is gains and "losses"---e.g., no generics etc.).
InfoQ: You have praised the compactness of the Go language, but Is there anything you would like to see added? (With the possible exception of operator overloading and generics.)
Mark: I think you can have operator overloading without generics. But the only thing I really miss is an ordered map (although in my book I provide a Go implementation of a left-leaning red-black tree as an example that also fills that particular gap:-)
InfoQ: Your book has an appendix that addresses the dangers of patent trolls. What prompted you to include this? Do you think it was necessary to raise awareness of the issue or was something in particular?
Mark: I don't like patents at all: I believe them to be anti-competitive and to favour big organizations over small. For software, copyright is perfectly sufficient. I included the appendix because I've now started to hear about programmers who have had to withdraw software from the US market (e.g., people writing iOS apps) because the alternative was to pay "protection money" to patent Trolls. Software patents make it much harder for individual programmers or small teams to compete and I think this is not just a shame but morally wrong.
Over the past few years I've had some ideas for commercial software: niche products that would be useful but not huge sellers. However, I'm not prepared to put in the time because my main market would be the US and it would be uneconomic for me to risk all that time and effort only to have so much of it "stolen" by patent Trolls.
About the Book Author
Mark Summerfield graduated in computer science with first class honours from the University of Wales Swansea. He followed this with a year’s postgraduate research before going into industry. He spent many years working as a software engineer for a variety of firms before joining Trolltech. He spent almost three years as Trolltech’s documentation manager, during which he founded and edited Trolltech’s technical journal, Qt Quarterly. Mark is the coauthor of C++ GUI Programming with Qt 3 and C++ GUI Programming with Qt 4, and author of Rapid GUI Programming with Python and Qt: The Definitive Guide to PyQt Programming. Mark owns Qtrac Ltd., where he works as an independent author, editor, trainer, and consultant, specializing in C++, Qt, Python, and PyQt.
