In early 2012, I have a new book coming out, The Go Programming Language Phrasebook. This is something of a change for me, as the previous two books had been about Objective-C. I thought I'd spend a little bit of time introducing Go to people who are familiar with Objective-C. After the 1.0 release, I hope that Go will become a supported development language for Android, so it makes sense for anyone who does iOS development to consider learning it.
This article gives a high-level overview of the similarities and differences between the two languages. In parts 2 and 3, we'll look at the syntax in more detail. These articles aren't intended to replace a book about Go, or the Go specification; instead, they're intended to give a high-level overview of the language for people who are considering learning it.
At the abstract machine level, Go and Objective-C have a lot in common. They both have primitive value types for things like integers and operations on them that can be compiled to very short sequences of machine instructions. They both have the ability to call functions directly with compile-time binding, but also the ability to do late-bound dynamic dispatch.
The biggest difference between the two languages is the memory model. Go is designed to support garbage collection, and it doesn't allow the kind of fluid transformation between pointers and integers that C permits. Objective-C has recently moved in this direction a bit with the addition of automatic reference counting, which requires explicit bridged casts to turn an object pointer into some other kind of value. With Go, turning a pointer into an integer (or vice versa) requires the unsafe package, which isn't supported in managed environments such as the Google App Engine.
Garbage collection also means that there's no real concept of "stack" and "heap" in Go. If you declare a local variable, it will probably be allocated on the stack. If you take its address, it will probably be allocated on the heap. Neither of these results is guaranteed: If it's large, it may end up on the heap anyway, and if the compiler can prove that the pointer doesn't persist beyond the function call, then it may remain on the stack.
The Go abstract model also has concurrency built in. In Objective-C (and pure C), concurrency is an afterthought and is provided by the library. If you're using Objective-C, then you probably use libdispatch for running things in parallel. In Go, you have similar capabilitiesand a few morein the language.