
Go for Objective-C developers - mergesort
http://runtimeintrospection.tumblr.com/post/76441664061/go-for-objective-c-developers
======
pornel
I don't feel like I've learned much about Go from this article.

    
    
        make(chan bool, 1)
    

what is that 1 for? Why is it not using constructor sytnax shown earlier?
(`Chan{bool}` or `BoolChan{1}`?)

`go function` is nice, but in ObjC there's `dispatch_async()` and
`NSOperationQueue`. Go does some magic with green threads, segmented stacks
and whatnot, but the article doesn't elaborate.

And for an Objective-C developer Go's lack of proper interoperability with
Cocoa is disappointing:

[http://stackoverflow.com/questions/6322194/cocoa-bindings-
fo...](http://stackoverflow.com/questions/6322194/cocoa-bindings-for-the-go-
language)

BTW:

    
    
       (CGRect){0, 0, 320, 480}
    

is valid in ObjC (doesn't apply to classes though).

~~~
mergesort
As for (CGRect){0, 0, 320, 480}, it is indeed valid, but it's a lot nicer to
have a consistent syntax instead of mixing C with Objective-C.

~~~
micampe
There is no mixing. Objective-C is a superset of C, therefore C syntax is part
of the Objective-C language.

~~~
mergesort
Mixing in the sense that ABAddressBook is a C based API, with no Cocoa
wrapper, like how CGRect is a struct, not an class.

------
sdegutis
> _If software development is about reducing mental strain on a programmer,
> then garbage collection is something that goes a long way to that._

Go's GC has its own caveats that you have to watch out for. It doesn't really
save you from having to think about your object graph or architecture design.

~~~
Moto7451
I thought the GC point was kind of interesting seeing as Objective C does/did
have Garbage Collection (if you're an OS X developer). It's been deprecated
and ARC is the replacement. There's been a bit of discussion about this in the
past. Maybe if the first iPhone had come with the same hardware we're looking
at today the story would be different but I tend to agree with the reasoning
behind not supporting GC on iDevices. I feel like the hoops (some types of)
Game developers have to jump through on Android even with todays hardware is
validation of Apple's reasoning.

[http://www.cocoabuilder.com/archive/xcode/322876-why-arc-
ove...](http://www.cocoabuilder.com/archive/xcode/322876-why-arc-over-garbage-
collection.html)

[http://daringfireball.net/linked/2011/09/19/the-
unfamiliar](http://daringfireball.net/linked/2011/09/19/the-unfamiliar)

[http://stackoverflow.com/questions/2484079/how-can-i-
avoid-g...](http://stackoverflow.com/questions/2484079/how-can-i-avoid-
garbage-collection-delays-in-java-games-best-practices?rq=1)

~~~
pjmlp
Apple failed to develop a stable GC for Objective-C, there were lots of issues
when linking with libraries that did not make use of it.

Plus the underlying C part, didn't allow for more than a plain conservative
GC.

ARC works by generating the retain/release calls the developers would write
anyway with NeXTStep/Cocoa framework.

So while it is a good solution for Objective-C, it isn't because it thrumps
GC, but rather due to Apple's failure with a stable GC.

~~~
sdegutis
I would argue a step further and say that it's because Apple chose the wrong
solution for an OOP language with C-compatibility. They could have invented a
language more like C# for NeXTSTEP, but they chose the route with easier C
compatibility. Now they're paying the cost of taking that early shortcut.

~~~
Moto7451
Given the development timeframe for NeXTSTEP, I don't think that a managed
language would have been a likely choice. Remember, this is when your average
barn burner workstation came with a 33MHz 386 Class CPU and 4-8MB of memory.
The NeXT Computer came with a 25MHz '030 and 8MB of memory.

~~~
pjmlp
They could, as Xerox PARC machines were not as powerful and offered:

\- Lisp OS

\- Smalltalk OS

\- Mesa/Cedar (a GC enabled systems programming)

------
dengnan
Before any insightful discussion, may I suggest that we do not discuss
generics?

~~~
justin66
Let me guess, you're worried that the Objective C team will get swamped with
requests for generics by developers who behave as if it is impossible to
develop software without the feature.

Never happen. The HN community is far too mature for that.

~~~
plorkyeran
The lack of generics in Objective-C is one of my biggest complains with the
language. A huge portion of the runtime errors I run into are due to
containers not containing the type of object I expected them to.

------
higherpurpose
Could Go be used to replace Java on Android eventually? If he's already
comparing it to Objective-C, and since it already has garbage collection, it
might not be a terrible idea, and it should make it easier for new programmers
wanting to develop for Android, since Go is an easier language to learn than
Java and much less verbose.

~~~
Touche
Most of Android is written in Java, so no, that's not going to happen in our
lifetimes. All we can hope is that ART is good enough that Dalvik goes away
and we can start building stable languages on top of ART (as opposed to with
Dalvik which only has immature / experimental languages not-named-Java.

~~~
MBCook
> Most of Android is written in Java, so no, that's not going to happen in our
> lifetimes.

It could easily happen if Google wanted it to. Java can call native code (and
vice-versa). Other system vendors have changed core implementations before.
Apple has pulled it off 2 or 3 times at least.

It wouldn't be easy, but it's certainly possible.

~~~
Touche
Yeah, absolutely, but they'd have to have a very good reason to do so. I want
them to do it too, but I doubt it will happen unless they reach some major
roadblock that makes ART unsuitable.

------
jamieomatthews
Great article! I'd like to see a part 2 to this article where you go a bit
more in depth into some differences, with examples of both golang code and
objectiv-c code. Thanks!

------
gilgoomesh
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.

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.

 _First heading from the article: "Not traditionally object-oriented"_

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).

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.

 _Second heading from the article: "Type inference"_

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

 _Third heading from the article: "Garbage collecting"_

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.

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.

 _Fourth heading from the article: "Native concurrency"_

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.

 _Fifth heading from the article: "Packages"_

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.

Also... it is _really_ 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.

~~~
plorkyeran
> 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

You lose compile-time type checking with id, so it's not at all like type
inference. I'm not sure how ARC is relevant at all, as it changed nothing
about how id works. Using id everywhere is pretty similar to using void *
everywhere in C.

