As an Objective-C developer, I simply don't think Go solves the same problems as Objective-C – comparing the two seems very apples and oranges to me. If I ever start using Go, it won't be as a direct replacement for Objective-C.<p>I don't mean to attack the author (I enjoyed the article) but most of Go's "advantages" are also disadvantages when used in an Objective-C/Cocoa environment.<p><i>First heading from the article: "Not traditionally object-oriented"</i><p>The problem with this is that much of Objective-C is focussed on the AppKit/UIKit view-hierarchy. As the Rust developers noticed when trying to implement the HTML DOM in their Servo project, large hierarchies of similar entities are cumbersome and require repeating yourself often if you don't have access to traditional subclasses. Rust eventually added single inheritance (despite earlier pushing for a purely Go-like compositional interface approach).<p>Compositional interfaces are a good thing... but so is data and behavioral inheritance. Taking one of these things away makes the language poorer, not richer. Yes, compositional interfaces would be good in Objective-C but a lack of inheritance in Go isn't a perfect world either.<p><i>Second heading from the article: "Type inference"</i><p>For the mostpart, this is a point in Go's favor. Although the author might not realise that with ARC in Objective-C you can actually just duck type if you want (type as 'id') and the ARC compiler will do type inference behind your back to track memory so you still get all the compile-time checks and other type inference advantages<p><i>Third heading from the article: "Garbage collecting"</i><p>Ignoring the technical problems with Apple's GC implementation for Objective-C, there were three real reasons why garbage collection sucked badly: (1) it used too much RAM (standard GC drawback), (2) it was slow (because it used too much RAM – it was otherwise efficient), but most critically: (3) it removed deterministic deletion which is critical in Cocoa.<p>Cocoa relies on its destructors to perform actual work. With GC, you suddenly can't rely on destructors being invoked when you need them. The idea that GC "reduc[es] mental strain" does not apply if instead of transparent lifecycle management with ARC, you suddenly need completely manual "dispose" methods everywhere.<p><i>Fourth heading from the article: "Native concurrency"</i><p>Apple's approach to native concurrency is that you should use libdispatch. It's slightly more verbose than prefixing a function with "go" but it handles all that go's built-in concurrency handles and actually much more. I think, from its exclusion, that the author is unfamiliar with libdispatch. I've not seen evidence that go has any built in advantages over libdispatch.<p><i>Fifth heading from the article: "Packages"</i><p>On namespaces: yes, they allow for ways around conflicts. But there is a double edged sword here: names in different namespaces are going to conflict. If you've used a large library like .NET, you'll know what I mean: lots of different classes in different namespaces conflict so that you can't simply say "using XXX" for each namespace and instead you have to reference the whole path. Instead of NSTimer you have to use System.Timers.Timer or System.Threading.Timer – a two letter prefix is now fourteen or seventeen letters.<p>Also... it is <i>really</i> annoying attempting to follow sample code when the sample code omits all the namespace inclusions. You're trying to learn the API from the code but the code doesn't explain what API it's using forcing you to trial and error hunt around for the correct namespace.