Journey Through Go

A few years ago the release of the Go programming language was announced, but I ignored it until I recently
discovered it was being used on large back-end systems at Heroku and at Google.  I also discovered that the Go team  included Rob Pike (formerly from Bell Labs and member of the Unix team) and Ken Thompson (also from Bell Labs
and worked on Unix and the C language), so I knew this language deserved looking into.  As I read more about Go and toyed with it during some of my spare time, I became quite impressed.  

For the majority of my career, C/C++ were my weapons of choice, but during the past few years, Ruby and C# have  been added to my arsenal.  Through my progression of different languages, I developed a sense of appreciation for both low level and high level languages.  Go merges the best of both worlds by giving the high level language feel, but compiles down to native code to run with low level performance.  Even with the high level feel, its feature set is very small and you don’t have to read a whole textbook to know all about it.

Plus Ones

• Concurrency is easy and safe through the use of go routines and communication between go routines using channels (message passing).  Parallelism is easy as setting a value (GOMAXPROCS=4)  (Read Rob Pike’s talk on why concurrency isn’t parallelism: http://concur.rspace.googlecode.com/hg/talk/concur.html#hello)
• The compiler: It’s uber fast.  Also on C/C++ compilers, normally what would be warnings are errors on Go to keep the code clean.  For example, unused variables are treated as  errors.
• The Go package comes with a great set of tools to compile, format, and update your code from a previous version.
• With version 1, the Go build tool eliminates the need for Makefiles. If you’ve worked with Makefiles before, this alone should attract you to Go :)
• It’s not tied in with an IDE like some of the byte-code compiled languages such as Java and C#.
• The Go formatting tool forces everyone to follow the same code format.  You won’t have to suffer from identity crisis working in different source code repositories.
• No exceptions, except for the global ‘panic’ exception.  In systems programming, unhandled or unknown exceptions usually cause bad side effects.  Go facilitates error checking by allowing functions to return multiple return values.  This forces error handling to be more explicit.
• OOP through interfaces.  For you Ruby programmers, think of duck typing but checked at compile time.  This prevents deep inheritance trees and make-everything-a-class-because-you-can baloney.  
• Slices.  These are pointers to arrays and they remind me of Matlab and Python slices.  Hopefully this feature will help attract more developers from the scientific computing community where Matlab and Python are widely used.

Minus point Five

• Naive garbage collection.  The current GC is bottlenecking Go’s full performance potential.  I’m confident the Go developers will improve this soon.
• The inability to turn off automatic garbage collection for more granular control on CPU usage.  Go lets you call the GC, but you can’t turn it off completely.  Unless you’re doing heavy number crunching, this generally isn’t an issue, but it’s a nice-to-have.
• Types come after a function or variable name.  It took a little while to get used to and there are worse formats out there.  ( *cough* Objective *cough* C)

In the list of Plus Ones, I may seem to be a hater of high level languages, but I'm really not.  I work with them almost everyday and I definitely would not use Go to code a UI application where deep abstraction and tight integration with an IDE have a place.  Go is great for what I mostly enjoy and that is on the backend.  Hopefully, this blog gave you a taste of a great up and coming language and I hope to show more code examples as I learn more about Go.

http://golang.org/